Diagrama de Comunicação. SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa
|
|
- Fábio Correia Dinis
- 5 Há anos
- Visualizações:
Transcrição
1 Diagrama de Comunicação SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de
2 2 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos de Uso Emprestar Livro A t o r P r i n c i p a l : A t e n d e n t e I n t e r e s s a d o s e I n t e r e s s e s : C a s o d e U s o : E m p r e s t a r L i v r o - A t e n d e n t e : d e s e j a r e g i s t r a r q u e u m o u m a i s l i v r o s e s t ã o e m p o s s e d e u m l e i t o r, p a r a c o n t r o l a r s e a d e v o l u ç ã o s e r á f e i t a n o t e m p o d e t e r m i n a d o. - L e i t o r : d e s e j a e m p r e s t a r u m o u m a i s l i v r o s, d e f o r m a r á p i d a e s e g u r a. - B i b l i o t e c á r i o : d e s e j a c o n t r o l a r o u s o d o s l i v r o s, p a r a q u e n ã o s e p e r c a m e p a r a q u e s e m p r e s e s a i b a c o m q u e l e i t o r e s t ã o n o m o m e n t o. P r é - C o n d i ç õ e s : O A t e n d e n t e é i d e n t i f i c a d o e a u t e n t i c a d o. Atendente Devolver Livro Leitor G a r a n t i a d e S u c e s s o ( P ó s - C o n d i ç õ e s ) : O s d a d o s d o n o v o e m p r é s t i m o e s t ã o a r m a z e n a d o s n o S i s t e m a. O s l i v r o s e m p r e s t a d o s p o s s u e m s t a t u s e m p r e s t a d o C e n á r i o d e S u c e s s o P r i n c i p a l : Bibliotecária Incluir Livro Comprar Livro Consultar Livro 1. O L e i t o r c h e g a a o b a l c ã o d e a t e n d i m e n t o d a b i b l i o t e c a e d i z a o a t e n d e n t e q u e d e s e j a e m p r e s t a r u m o u m a i s l i v r o s d a b i b l i o t e c a. 2. O A t e n d e n t e s e l e c i o n a a o p ç ã o p a r a r e a l i z a r u m n o v o e m p r é s t i m o. 3. O A t e n d e n t e s o l i c i t a a o l e i t o r s u a c a r t e i r a d e i d e n t i f i c a ç ã o, s e j a d e e s t u d a n t e o u p r o f e s s o r. 4. O A t e n d e n t e i n f o r m a a o s i s t e m a a i d e n t i f i c a ç ã o d o l e i t o r. 5. O S i s t e m a e x i b e o n o m e d o l e i t o r e s u a s i t u a ç ã o. 6. O A t e n d e n t e s o l i c i t a o s l i v r o s a s e r e m e m p r e s t a d o s. 7. P a r a c a d a u m d e l e s, i n f o r m a a o s i s t e m a o c ó d i g o d e i d e n t i f i c a ç ã o d o l i v r o. 8. O S i s t e m a i n f o r m a a d a t a d e d e v o l u ç ã o d e c a d a l i v r o. 9. S e n e c e s s á r i o, o A t e n d e n t e d e s b l o q u e i a o s l i v r o s p a r a q u e p o s s a m s a i r d a b i b l i o t e c a. 10. O L e i t o r s a i c o m o s l i v r o s. F l u x o s A l t e r n a t i v o s : (1-8). A q u a l q u e r m o m e n t o o L e i t o r i n f o r m a a o A t e n d e n t e q u e d e s i s t i u d o e m p r é s t i m o. 3. O L e i t o r i n f o r m a a o A t e n d e n t e q u e e s q u e c e u a c a r t e i r a d e i d e n t i f i c a ç ão. 1. O A t e n d e n t e f a z u m a b u s c a p e l o c a d a s t r o d o L e i t o r e p e d e a e l e a l g u m a i n f o r m a ç ã o p e s s o a l p a r a g a r a n t i r q u e e l e é m e s m o q u e m d i z s e r. 4. O L e i t o r e s t á i m p e d i d o d e f a z e r e m p r é s t i m o, p o r t e r n ã o e s t a r a p t o. 1.C a n c e l a r a o p e r a ç ã o. 7 a. O L i v r o n ã o p o d e s e r e m p r e s t a d o, p o i s e s t á r e s e r v a d o p a r a o u t r o l e i t o r. 1. O A t e n d e n t e i n f o r m a a o L e i t o r q u e n ã o p o d e r á e m p r e s t a r o l i v r o e p e r g u n t a s e d e s e j a r e s e r v á - l o. 2. C a n c e l a r a o p e r a ç ã o ( s e f o r o ú n i c o l i v r o ) 7 b. O L i v r o n ã o p o d e s e r e m p r e s t a d o, p o i s é u m l i v r o r e s e r v a d o s o m e n t e p a r a c o n s u l t a. 1. C a n c e l a r a o p e r a ç ã o ( s e f o r o ú n i c o l i v r o )
3 3 O que já foi visto até agora Casos de Uso com substantivos e verbos sublinhados Caso de Uso 1 1. OLeitor chegaaobalcãodeatendimentodabibliotecaedizaoatendentequedeseja emprestar umoumaislivrosdabiblioteca. 2. OAtendenteselecionaaopçãoparaadicionar umnovoempréstimo. 3. OAtendentesolicitaaoleitor suacarteirinha, sejadeestudanteouprofesor. 4. OAtendenteinformaaosistemaaidentificaçãodoleitor. 5. OSistemaexibeonomedoleitor esuasituação. 6. OAtendentesolicitaoslivrosaserememprestados. 7. Paracadaumdeles, informaaosistemaocódigodeidentificaçãodolivro. 8. OSistemainformaadatadedevoluçãodecadalivro. 9. OAtendentedesbloqueiaoslivrosparaqueposamsair dabiblioteca. 10. OLeitor sai comoslivros. Caso de Uso n Atendente nome Bibliotecaria nome n registra refere-se a > 1..1 Modelo Conceitual 1..1 Leitor nome tipo : char registra 0..n 0..n ^ faz n faz Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo n situação : Char 1..1 Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 0..1 corresponde a corresponde a possui 1..n 0..1 LinhaDoEmpréstimo data_prevista_devolução data_entrega_real 0..n < refere-se a 1. OLeitor chegaaobalcãodeatendimentodabibliotecaedizaoatendentequedeseja emprestar umoumaislivrosdabiblioteca. 2. OAtendenteselecionaaopçãoparaadicionar umnovoempréstimo. 3. OAtendentesolicitaaoleitor suacarteirinha, sejadeestudanteouprofesor. 4. OAtendenteinformaaosistemaaidentificaçãodoleitor. 5. OSistemaexibeonomedoleitor esuasituação. 6. OAtendentesolicitaoslivrosaserememprestados. 7. Paracadaumdeles, informaaosistemaocódigodeidentificaçãodolivro. 8. OSistemainformaadatadedevoluçãodecadalivro. 9. OAtendentedesbloqueiaoslivrosparaqueposamsair dabiblioteca. 10. OLeitor sai comoslivros. 0..n CopiaDoLivro nro sequencial situacao : char liberadoparaemprestimo : char 1..1
4 4 O que já foi visto até agora Modelo Conceitual + Casos de Uso Diagrama de Seqüência do Sistema (para cada caso de uso) :Atendente 1: iniciarempréstimo(id_leitor) Sistema 2: emprestarlivro(id_livro) * mais livros a emprestar 3: encerrarempréstimo()
5 5 O que já foi visto até agora Diagrama de Seqüência do Sistema (para cada caso de uso) Contrato da Operação (para cada operação) :Atendente Sistema Operação: encerrarempréstimo() 1: iniciarempréstimo(id_leitor) 2: emprestarlivro(id_livro) * mais livros a emprestar 3: encerrarempréstimo() Referências Cruzadas: Caso de uso: Emprestar Livro Pré-Condições: Umleitor apto a emprestar livros já foi identificado; pelo menos umlivro já foi identificado e está disponível para ser emprestado. Pós-Condições: umnovo empréstimo foi registrado; o novo empréstimo foi relacionado ao leitor já identificado na operação iniciar o empréstimo ; a situação dos livros emprestados foi alterada para emprestado.
6 Conclusão da Fase de Análise A fase de análise enfatiza uma compreensão dos requisitos do sistema Fazer a Coisa Certa compreender objetivos, conceitos e características do domínio do problema Artefatos estudados: Artefato da Análise Casos de Uso Modelo Conceitual Diagramas de Sequência do Sistema Questões respondidas Quais são os processos do domínio? Quais são os conceitos (objetos)? Quais são os eventos e operações? 6
7 Início da fase Projetar Nessa fase, é desenvolvida uma solução lógica baseada no paradigma de orientação a objetos objetos, mensagens, classes, métodos,. Fazer Certo a Coisa projetar de maneira competente uma solução que satisfaça os requisitos Os dois artefatos principais a serem desenvolvidos são: Diagramas de Interação Diagramas de Classe de Projeto 7
8 Diagramas de Interação Diagramas de Interação apresentam como os objetos interagem, por meio de mensagens, para responder a um determinado evento são importantes para o desenvolvimento de um bom projeto exigem criatividade A UML fornece dois tipos de diagramas de interação que permitem representar interação (colaboração) entre classes (ou objetos): diagramas de comunicação formato de grafo diagramas de seqüência formato de cerca 8
9 Diagrama de Comunicação mensagem1() :Instância da Classe A 1:mensagem2() 2:mensagem3() :Instância da Classe B Os diagramas de comunicação têm melhor capacidade de expressar informações contextuais e podem ser mais econômicos em termos de espaço 9
10 Diagrama de Sequência :instância de Classe A :instância de Classe B :instância de Classe C mensagem1() 1:mensagem2() 2:mensagem3() 3:mensagem4() 10
11 Diagramas de Comunicação Diagrama de Comunicação - um dos artefatos mais importantes criados no projeto OO o tempo gasto na sua criação deveria absorver um percentual de tempo significativo do tempo gasto no projeto Elaborar diagramas de comunicação exige conhecimento de: princípios de atribuição de responsabilidades padrões de projeto 11
12 Classes e Instâncias Classe Instância Instância nomeada Venda :Venda venda1:venda 12
13 Mensagens Sintaxe UML: retorno := mensagem ( parâmetro : tipoparâmetro ) : tiporetorno O retorno pode não existir Os tipos podem ser omitidos ser forem óbvios ou não forem importantes Exemplo: ( obterespecificacaoproduto(id especificacao := ( obterespecificacaoproduto(id:iditem especificacao := especificacao := obterespecificacaoproduto(id:iditem) : EspecificacaoProduto 13
14 Mensagens No paradigma de orientação a objetos: Mensagem é o mecanismo de comunicação entre objetos invoca as operações desejadas O processo de invocar um método é chamado de envio de uma mensagem ao objeto Ex: quando uma mensagem façaalgo() é enviada a uma objeto obj, o método façaalgo() definido na classe de obj é executado: () obj.façaalgo 14
15 Ligações Ligação: conexão em dois objeto que indica a possibilidade de alguma forma de navegação ou de visibilidade entre eles permite que mensagens fluam de um objeto para outro :TPV total:=totalizarvenda():float :Venda () Venda.totalizarVenda : 15
16 Mensagens Múltiplas Várias mensagens, em ambos os sentidos, podem fluir ao longo de uma mesma ligação usar seta para indicar direção da mensagem usar números de sequência para indicar ordem de execução das mensagens :Instância Classe A 1:mensagem1() 2:mensagem2() 3:mensagem3() () 4:mensagem4 :Instância Classe B 16
17 Exemplo () acionar :BotãoElevador ( 2:iluminar( ( 1:atualizar( :ControladorElevador 17
18 em algum lugar no sistema Primeira Mensagem A primeira mensagem é aquela enviada ao objeto que inicia o tratamento a um determinado evento O emissor da primeira mensagem não é identificado () primeiramsg :Instância Classe A 1:mensagem1() 2:mensagem2() 3:mensagem3() () 4:mensagem4 :Instância Classe B () InstÂnciaClasseA.primeiraMsg : 18
19 Exemplo () Aterrissar :Aeronave 1:ok :=posicionarangulo(angulo):booleano :Flape 19
20 Número de Sequência da Mensagem Primeira mensagem não é numerada Numeração formal e agregada indica a ordem e o aninhamento das mensagens msg1() :ClasseA 1:msg2() :ClasseB 1.1:msg3() aninhamento de mensagens :ClasseC 20
21 Aninhamento de Mensagens msg1() :ClasseA 1:msg2() :ClasseB () msg1 () ClasseB.msg2 : () msg2 () ClasseC.msg3 : 1.1:msg3() :ClasseC 21
22 Aninhamento de Mensagens Exemplo msg1() :ClasseA 1:msg2() :ClasseB 1.1:msg3() 2:msg4() 2.1:msg5() :ClasseC :ClasseD 2.2:msg6() 22
23 Aninhamento de Mensagens Exemplo (. cont ) () ClasseA.msg1 : em algum lugar no sistema () msg1 () ClasseB.msg2 : () ClasseC.msg4 : () msg2 () ClasseC.msg3 : () msg4 () ClasseB.msg5 : () ClasseD.msg6 : 23
24 Auto-Mensagem (this) () msg1 :ClasseA () msg2 :1 () iniciarsistema :TPV 1: iniciar() 24
25 Iteração msg1() () msg1 for i=1 to 10 { () ClasseB.msg2 : () ClasseC.msg3 : } :ClasseA () 1*:[i:=1..10]msg2 :ClasseB () 2*:[i:=1..10]msg3 :ClasseC 25
26 Iteração msg1() :TPV 1 * : linha:=proxlinhaitem():linhaitemvenda :Venda Cláusula de Iteração ([i:=1..10]) é opcional 26
27 Criação de Instância Uma mensagem pode ser usada para criar uma instância nomear mensagem como criar() mensagem criar(), com parâmetros opcionais, normalmente é interpretada, na :TPV iniciarvenda() 1:criar(caixa) implementação, como chamada a um construtor da classe de software :Venda 27
28 Mensagens Condicionais Uma mensagem condicional só será enviada se a cláusula entre [ ] tiver valor true :ClasseA msg1() 1: [condição] msg2() () msg1 :ClasseB if (condicao = true) { () ClasseB.msg2 : } 28
29 Mensagens Condicionais msg1() :TPV 1: [nova venda] criar() :Venda 29
30 Caminhos Condicionais Mutuamente Exclusivos Apenas uma ou outra mensagem é enviada dependendo da condição ser verdadeira ou falsa msg1() :ClasseA 1a: [condição] msg2() () msg1 if (condicao = true) () ClasseB.msg2 : () ClasseC.msg3 : else :ClasseB 1b:[not condição] msg3() :ClasseC 30
31 Caminhos Condicionais Mutuamente Exclusivos :ClasseE 2:msg6() msg1() :ClasseA 1a: [condição] msg2() :ClasseB 1b:[not condição] msg4() 1a.1:msg3() :ClasseD 1b.1:msg5() :ClasseC 31
32 Multiobjetos Um multiobjeto é uma coleção de instâncias, representada por um único ícone Uma mensagem pode ser enviada ao multiobjeto ou a cada membro da coleção 32
33 Mensagens para Multiobjetos :Venda msg1() mensagem enviada à coleção 1: qt:=obterquantidade( ) : Int ItemLinhaVenda :Venda msg1() 1*: id:=obterid( ) * ItemLinhaVenda mensagem enviada a cada membro da coleção 33
34 Exemplo TPV - DSS :Caixa iniciarnovavenda( ) Comprar Itens :Sistema entraritem(cup, quantidade) descrição item, total *[mais itens] terminarvenda() ( fazerpagamento(quantia troco, recibo 34
35 Exemplo TPV Modelo Conceitual Venda data hora 1..1 Capturada-em 1..1 TPV 1..1 Paga-por 1..1 Pagamento quantia 35
36 Exemplo TPV Diagrama de Comunicação ( fazerpagamento(quantia :TPV ( 1:fazerPagamento(quantia :Venda ( 1.1:criar(quantia :Pagamento 36
37 Portanto É importante ser consistente ao sublinhar os nomes de instância quando realmente se deseja uma instância; caso contrário, mensagens para instâncias versus mensagens para classes podem ser interpretadas incorretamente. 37
38 Exemplo de Diagrama de Comunicação: Calcular o total da compra subtotal() { return quantidade*prodspec.preço() } tot:=total() :Venda 1*:[para cada]liv:=prox() :LinhadeItemdeVenda 2: st:=subtotal() liv:linhadeitem devenda total() { tot:=0 para cada linha de item de venda liv tot:= tot + liv.subtotal() } 2.1:pr:=preço prodespec: Especifi caçãodeproduto 38
39 GRASP: Padrões para Atribuição de Responsabilidades 39
40 Responsabilidade Responsabilidade um contrato ou obrigação de um tipo ou classe ( subsistema serviços fornecidos por um elemento (classe ou incorpora os objetivos de um elemento Dois tipos de responsabilidades básicas: Fazer (, operação fazer algo (criar um objeto, executar uma iniciar ações em outros objetos coordenar e controlar atividades em outros objetos Saber conhecer dados privados encapsulados conhecer objetos relacionados conhecer coisas que podem ser derivadas ou calculadas 40
41 Responsabilidade Exemplos: uma Venda é responsável por criar ItemLinhaVenda FAZER uma Venda é responsável por conhecer o seu total - SABER OBS: responsabilidades do tipo saber frequentemente podem ser deduzidas do modelo ( associações conceitual (atributos e 41
42 Responsabilidades e Diagramas de Comunicação Diagramas de comunicação mostram escolhas de atribuição de responsabilidade a objetos Exemplo: atribuir aos objetos do tipo Venda a responsabilidade de imprimirem a si próprios. imprimir() :Venda Responsabilidade de imprimir a si própria 42
43 Responsabilidade A tradução de responsabilidade em classes e métodos é influenciada pela granularidade da responsabilidade. Ex: Fornecer acesso a bancos de dados relacionais pode envolver muitas classes e métodos Imprimir uma venda pode envolver apenas um ou alguns poucos métodos Os métodos são implementados para satisfazer uma responsabilidade Um objeto pode colaborar com outros objetos para atender a uma responsabilidade 43
44 Exemplo ( fazerpagamento(quantia :Venda ( 1:criar(quantia Responsabilidade Fazer Pagamento atribuída ao objeto Venda colaboração entre Venda e Pagamento :Pagamento 44
45 Padrões Desenvolvedores de software experientes criaram um repertório de princípios gerais e boas soluções para guiar a construção de softwares Essas soluções foram descritas em um formato padronizado (nome, problema, solução) e podem ser usadas em outros contextos Padrões usualmente não contêm novas ideias organizam conhecimentos e princípios existentes, testados e consagrados Padrão é uma descrição nomeada de um problema e uma solução, que pode ser aplicado em novos contextos 45
46 Padrões GRASP GRASP = General Responsibility Assignment Software Patterns Descrevem princípios fundamentais de atribuição de responsabilidade a objetos Principais padrões GRASP: ( Expert ) Especialista ( Creator ) Criador ( Cohesion Coesão alta (High ( Coupling Acoplamento fraco (Low ( Controller ) Controlador 46
47 Especialista Problema: qual é o princípio mais básico de atribuição de responsabilidades a objetos? Solução: Atribuir responsabilidade ao especialista da informação. Exemplo: no sistema TPV, alguma classe precisa conhecer o total geral de uma venda 47
48 Exemplo Venda conhece o total da venda ItemLinhaVenda conhece o subtotal da linha EspecificaçãoProduto conhece o preço do produto. 48
49 t:=obtertotal( ) :Venda 1*: st:=obtersubtotal( ) * :LinhadeItemdeVenda 1.1: p:=obterpreço( ) :Especificaçãode Produto
50 Especialista Discussão É o padrão mais utilizado Fazê-lo eu mesmo objetos fazem coisas relacionadas à informação que têm Lembrar que existem especialistas parciais que colaboram numa tarefa informação espalhada comunicação via mensagens Tem uma analogia no mundo real 50
51 Especialista Benefícios: Mantém encapsulamento favorece o acoplamento fraco O comportamento fica distribuído entre as classes que têm a informação necessária (classes leves ) favorece alta coesão Contra-indicações contra indicado quando aumenta acoplamento e reduz coesão Ex: quem é responsável por salvar uma Venda no banco de dados? 51
52 Criador Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe? Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira: B agrega/contém/registra objetos de A B usa objetos de A B tem os valores iniciais que serão passados para objetos de A, quando de sua criação 52
53 Criador Exemplo: No sistema TPV, quem é responsável pela criação de uma instância de ItemLinhaVenda? ( quantidade ) criaritemlinha :Venda Venda contém vários itens de linha de venda ( 1:criar(quantidade :ItemLinhaVenda 53
54 Criador Discussão objetivo do padrão: definir como criador o objeto que precise ser conectado ao objeto criado em algum evento escolha adequada favorece acoplamento fraco objetos agregados, contêineres e registradores são bons candidatos à responsabilidade de criar outros objetos algumas vezes o candidato a criador é o objeto que conhece os dados iniciais do objeto a ser criado Ex: Venda e Pagamento 54
55 Exemplo ( fazerpagamento(quantia :Venda ( 1:criar(quantia Venda possui dados iniciais do pagamento :Pagamento 55
56 Criador Benefícios favorece o acoplamento fraco provavelmente o acoplamento não é aumentado porque o objeto criado provavelmente já é visível para o objeto criador, devido às associações existentes que motivaram sua escolha como criador 56
57 Acoplamento Acoplamento: dependência entre elementos (classes, subsistemas, ), normalmente resultante de comunicação para atender a uma responsabilidade O acoplamento mede o quanto um objeto está conectado a, tem conhecimento de ou depende de outros objetos acoplamento fraco (ou baixo) um objeto não depende de muitos outros acoplamento forte (ou alto) um objeto depende de muitos outros 57
58 Acoplamento Problemas do acoplamento alto: mudanças em classes interdependentes forçam mudanças locais dificulta a compreensão do objetivo de cada classe dificulta reutilização 58
59 Acoplamento Fraco Problema: como favorecer a baixa dependência e aumentar a reutilização? Solução: Atribuir responsabilidade de maneira que o acoplamento permaneça baixo. Exemplo: No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa? 59
60 Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV ( fazerpagamento( :TPV ( criar( 1: p:pagamento ( adicionarpagamento(p : 2 :Venda Projeto 2: alternativa responsabilidade atribuída à Venda ( fazerpagamento( :TPV ( Pagamento( 1: fazer ( criar( 1.1: :Venda :Pagamento
61 Qual projeto é melhor? Qual dos projetos anteriores favorece o acoplamento fraco? em ambos os casos, Venda será acoplada a (terá conhecimento de) Pagamento projeto 1 acoplamento entre Pagamento e TPV projeto 2 não aumenta acoplamento PREFERÍVEL 61
62 Formas de Acoplamento Um objeto tem um atributo que referencia um objeto de outra classe Um objeto tem um método que referencia um objeto de outra classe parâmetro, variável local ou retorno Um objeto invoca os serviços de um objeto de outra classe Uma classe é subclasse de outra, direta ou indiretamente 62
63 Acoplamento Fraco Discussão: Acoplamento fraco classes mais independentes reduz impacto de mudanças favorece reúso de classes Considerado em conjunto com outros padrões Extremo de acoplamento fraco não é desejável fere princípios da tecnologia de objetos comunicação por mensagens projeto pobre: objetos inchados e complexos, responsáveis por muito trabalho baixa coesão 63
64 Acoplamento Fraco Discussão: dica: concentre-se em reduzir o acoplamento em pontos de evolução ou de alta instabilidade do sistema ex: cálculo de impostos terceirizados no sistema TPV Benefícios: classe são pouco afetadas por mudanças em outras partes classes são simples de entender isoladamente conveniente para reutilização 64
65 Coesão Coesão mede o quanto as responsabilidades de um elemento (classe, objeto, subsistema, ) são fortemente focalizadas e relacionadas Objeto com Coesão Alta objeto cujas responsabilidades são altamente relacionadas e que não executa um volume muito grande de trabalho Objeto com Coesão Baixa objeto que faz muitas coisas não relacionadas ou executa muitas tarefas difícil de compreender, reutilizar e manter constantemente afetadas por mudanças 65
66 Coesão Alta Problema: Como manter a complexidade sob controle? Solução: Atribuir responsabilidade de tal forma que a coesão permaneça alta. Exemplo (o mesmo para o acoplamento fraco): No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa? 66
67 Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV ( fazerpagamento( :TPV ( criar( 1: p:pagamento ( adicionarpagamento(p : 2 :Venda O TPV toma parte na responsabilidade de fazer pagamento. Neste exemplo, isso seria aceitável, mas o que aconteceria se houvessem 50 mensagens recebidas por TPV?
68 Projeto 2: alternativa responsabilidade atribuída à Venda fazerpagamento( ) :TPV 1: fazer Pagamento( ) 1.1: criar( ) :Venda :Pagamento Esta solução favorece uma coesão mais alta em TPV e também um acoplamento mais fraco. Portanto, projeto 2 é preferível.
69 Coesão Alta Discussão: Coesão alta, assim como Acoplamento Fraco, são princípios que devem ser considerados no projeto de objetos má coesão traz acoplamento ruim e vice-versa regra prática: classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades relacionadas, e não executa muito trabalho analogia com mundo real ex: pessoas que assume muitas responsabilidades não associadas podem tornar-se (e normalmente tornam-se) ineficientes 69
70 Coesão Alta Benefícios mais clareza e facilidade de compreensão no projeto simplificação de manutenção e acréscimo de funcionalidade/melhorias favorecimento do acoplamento fraco aumento no potencial de reutilização classe altamente coesa pode ser usada para uma finalidade bastante específica 70
71 Controlador Problema: Quem deve ser responsável por tratar um evento do sistema? Solução: A responsabilidade de receber ou tratar as mensagens de eventos (operações) do sistema pode ser atribuída a uma classe que: represente todo o sistema, um dispositivo ou um subsistema chamado de controlador fachada - OU represente um cenário de um caso de uso dentro do qual ocorra o evento TratadorDe<NomeDoCasoDeUso>, ControladorDe<NomeDoCasoDeUso> 71
72 Controlador Exemplo: quem vai tratar os eventos do sistema TPV? Comprar Itens :Sistema :Caixa iniciarnovavenda( ) entraritem(cup, quantidade) descrição item, total *[mais itens] terminarvenda() fazerpagamento(quantia) troco, recibo 72
73 ID Item Quantidade :Caixa Entrar Item ( açãoexecutada(eventodaação Camada de Interface :CWindow ( quantidade entraritem(itemid, Camada do Domínio :????
74 Exemplo: Opções de Controlador todo o sistema (controlador fachada): TPV um tratador artificial do caso de uso: ControladorDeComprarItem entraritem( ) :TPV entraritem( ) :ControladorDe ComprarItem 74
75 Discussão: Controladores Fachada Um controlador fachada deve ser um objeto (do domínio) que sugira uma cobertura sobre outras camadas e que seja o ponto principal para as chamadas provenientes da interface com o usuário ou de outros sistemas pode ser uma abstração de uma entidade física ex: TPV pode ser um conceito que represente o sistema ex: sistematpv São adequados quando não há uma quantidade muito grande de eventos de sistema Não é possível redirecionar mensagens do sistema para controladores alternativos (ex: outros subsistemas ) 75
76 Discussão :Controladores de Casos de Uso Deve existir um controlador diferente para cada caso de uso Não é um objeto do domínio, e sim uma construção artificial para dar suporte ao sistema. Ex: ControladorDeComprarItem, ControladorDeDevolução Pode ser uma alternativa se a escolha de controladores fachada deixar a classe controladora com alto acoplamento e/ou baixa coesão (controlador inchado por excesso de responsabilidade) É uma boa alternativa quando existem muitos eventos envolvendo diferentes processos. 76
77 Controladores inchados Classe controladora mal projetada - inchada coesão baixa falta de foco e tratamentos de muitas responsabilidades Sinais de inchaço: uma única classe controladora tratando todos os eventos, que são muitos. Comum com controladores fachada o próprio controlador executa as tarefas necessárias para atender o ( especialista evento, sem delegar para outras classes (coesão alta, não controlador tem muitos atributos e mantém informação significativa sobre o domínio, ou duplica informações existentes em outros lugares 77
78 Controlador Curas para controladores inchados acrescentar mais controladores misturar controladores fachada e de casos de uso delegar responsabilidades Corolário: objetos de interface (como objetos janela ) e da camada de apresentação não devem ter a responsabilidade de tratar eventos do sistema 78
79 Controlador Benefícios: aumento das possibilidades de reutilização de classes e do uso de interfaces plugáveis. conhecimento do estado do caso de uso controlador pode armazenar estado do caso de uso, garantindo a sequência correta de execução de operações 79
80 ID Item Quantidade :Caixa Entrar Item ( açãoexecutada(eventodaação Camada de Interface :CWindow ( quantidade entraritem(itemid, Camada do Domínio :TPV :Venda ( quantidade criaritemlinhavenda (itemid,
81 Exemplo: Acoplamento Apache syscall graph
82 Exemplo: Acoplamento IIS6 syscal graph
DIAGRAMA DE COMUNICAÇÃO
Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação DIAGRAMA DE COMUNICAÇÃO SSC 621: Análise e Projeto Orientados a Objetos Prof. Dr. Lucas Bueno R. Oliveira 2º Semestre 2015 O
Leia maisGRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES. SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa
GRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2016 1 RESPONSABILIDADE Responsabilidade um contrato ou
Leia maisDIAGRAMA DE COMUNICAÇÃO. SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa
DIAGRAMA DE COMUNICAÇÃO SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2016 1 O QUE JÁ FOI VISTO ATÉ AGORA Casos de Uso Completo Abstrato Diagrama de Casos
Leia maisEngenharia de Software II
Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Engenharia de Software II Aula 01 (rogerio@fct.unesp.br) Bibliografia Básica PRESSMAN, R.
Leia maisDiagramas de Sequência do Sistema e Contratos de Operações. SSC-121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2012
Diagramas de Sequência do Sistema e Contratos de Operações SSC-121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2012 1 O que já foi visto até agora Casos de Uso Completo Abstrato
Leia maisNotação Básica dos Diagramas de Comunicação
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Notação Básica dos Diagramas de Comunicação Projeto e Desenvolvimento
Leia maisAula 5 Diagramas de Seqüência do Sistema e Contratos de Operações
Departamento de Sistemas de Computação Universidade de São Paulo Análise e Projeto Orientados a Objetos Aula 5 Diagramas de Seqüência do Sistema e Contratos de Operações Responsável Prof. Seiji Isotani
Leia maisAula 6 Notação Básica dos Diagramas de Comunicação
Departamento de Sistemas de Computação Universidade de São Paulo SSC 124 Análise e Projeto Orientados a Objetos Aula 6 Notação Básica dos Diagramas de Comunicação Responsável Prof. Seiji Isotani (sisotani@icmc.usp.br)
Leia maisDiagramas de Colaboração e Padrões GRASP
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de Informação Diagramas de Colaboração
Leia maisAula 7 Visibilidade entre objetos e Diagramas de Classes
Departamento de Sistemas de Computação Universidade de São Paulo SSC 124 Análise e Projeto Orientados a Objetos Aula 7 Visibilidade entre objetos e Diagramas de Classes Responsável Prof. Seiji Isotani
Leia maisPadrões de Projeto de Software
Padrões de Projeto de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático Padrões Básicos Information Expert Creator High Cohesion Low Coupling Controller Padrões Avançados
Leia maisDiagramas de Classes. SSC-526 Análise e Projeto Orientados a Objeto Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2013
Diagramas de Classes SSC-526 Análise e Projeto Orientados a Objeto Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2013 1 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos de
Leia maisANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3)
ANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3) Profª Andrea Padovan Jubileu Desenvolvimento Iterativo de Software (LARMAN, 2007) Desenvolvendo Software com UML 2.0 (MEDEIROS, 2004) Modelo de Projeto O
Leia maisNotação Básica dos Diagramas de Comunicação
Notação Básica dos Diagramas de Comunicação Análise e Projeto Orientados a Objetos Profa Rosana 1 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos de Uso Emprestar Livro A
Leia maisModelagem de Software
Modelagem de Software Engenharia de Software Rosana T. Vaccare Braga Material adaptado a partir de material da Profa. Simone Senger Souza ICMC/USP São Carlos Modelagem Construção de modelos abstratos Auxílio
Leia maisContratos O diagrama de sequência não menciona a funcionalidade das operações. Isto é, o comportamento do sistema Contrato é um documento que
Contratos Contratos O diagrama de sequência não menciona a funcionalidade das operações. Isto é, o comportamento do sistema Contrato é um documento que descreve o que uma operação promete cumprir As pré-
Leia maisAnálise do Sistema Casos de Uso
As Fases do PU 1 Análise do Sistema Casos de Uso Casos de Uso Completo Abstrato Diagrama de Casos de Uso Emprestar Livro Ator Principal: Atendente Interessados e Interesses: Caso de Uso: Emprestar Livro
Leia maisProjeto Orientado a Objetos
Projeto Orientado a Objetos Ivan Mathias Filho Toacy Cavalcante de Oliveira Design Orientado a Objetos Após a identificação dos requisitos e a criação do modelo de domínio, devemos adicionar os métodos
Leia maisGRASP. Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)
GRASP Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Introdução a padrões O que são? Por que utilizá-los? Padrões GRASP O que são? Quais serão apresentados na disciplina?
Leia maisEstudo de Caso TPV Projetando uma solução com objetos e Padrões GRASP
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de Informação Estudo de Caso
Leia maisDIAGRAMA DE CLASSES DE PROJETO
Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação DIAGRAMA DE CLASSES DE PROJETO SSC 621: Análise e Projeto Orientados a Objetos Prof. Dr. Lucas Bueno R. Oliveira 2º Semestre
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 4 Design Baseado em Responsabilidades 1 Programa Capítulo 4 Design Baseado em Responsabilidades
Leia maisAnálise e Projeto Orientados a Objetos: Visibilidade Diagrama de Classe de Projeto
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientados a Objetos: Visibilidade Diagrama de Classe
Leia maisEstudo de Caso TPV: do Projeto para a Codificação
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de Informação Estudo de Caso
Leia maisPadrões GRASP. Leonardo Gresta Paulino Murta
Padrões GRASP Leonardo Gresta Paulino Murta leomurta@ic.uff.br Introdução Estilo MVC Padrões Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Don t Talk to
Leia maisAnálise e Projeto Orientados por Objetos
Análise e Projeto Orientados por Objetos Aula 03 Padrões de Projeto GRASP Edirlei Soares de Lima Padrões de Projeto de Software Problemas no desenvolvimento de software se repetem...
Leia maisConteúdo. 1. Introdução. 2. Levantamento de Requisitos. 3. Análise Orientada a Objetos. 4. Projeto Orientado a Objetos 5. UML. 6.
Conteúdo 1. Introdução 2. Levantamento de Requisitos 3. Análise Orientada a Objetos 4. Projeto Orientado a Objetos 5. UML 6. Métodos Ágeis Projeto Orientado a Objetos Definição das Operações Responsabilidade
Leia maisIntrodução a Padrões, GRASP. Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé)
Introdução a Padrões, GRASP Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Processo de Desenvolvimento de Software Visão geral de processo Processos
Leia maisDiagrama de Classes Aula 11 (parte 1)
Universidade Federal de Mato Grosso do Sul Sistemas de Informação - CPCX Diagrama de Classes Aula 11 (parte 1) Prof. Fernando Maia da Mota Slides gentilmente cedidos por Profa. Dra. Maria Istela Cagnin
Leia maisPROJETO DE ARQUITETURA
PROJETO DE ARQUITETURA Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Próximas aulas: Seminários de Padrões de Projeto GoF 1º Dia: 10/11/2017, 08h 10h, Sala 04 2º Dia:
Leia maisConteúdo. 1. Introdução. 2. Levantamento de Requisitos. 3. Análise Orientada a Objetos. 4. Projeto Orientado a Objetos 5. UML. 6.
Conteúdo 1. Introdução 2. Levantamento de Requisitos 3. Análise Orientada a Objetos 4. Projeto Orientado a Objetos 5. UML 6. Métodos Ágeis Projeto Orientado a Objetos Projeto Orientado a Objetos Durante
Leia maisModelo Conceitual. Prof. Seiji Isotani Slides baseados no material da Profa Dra Rosana T. V. Braga
Departamento de Sistemas de Computação Universidade de São Paulo Análise e Projeto Orientados a Objetos Modelo Conceitual Prof. Seiji Isotani (sisotani@icmc.usp.br) Slides baseados no material da Profa
Leia maisPadrões para atribuir responsabilidades: Expert
Padrão para atribuir responsabilidades: Expert Introdução Um sistema OO é composto de objetos que enviam mensagens uns para os outros Uma mensagem é um método executado no contexto de um objeto Escolher
Leia maisPCS3413 Engenharia de Software e Banco de Dados
PCS3413 Engenharia de Software e Banco de Dados Aula 23 Escola Politécnica da Universidade de São Paulo 1 Acoplamento! Indica dependência entre classes.! Deve ser o menor possível.! Direcionar associações
Leia maisDescrição de Casos de Uso (Casos de Uso Textuais) SSC 124: Análise e Projeto Orientados a Objetos Profa. Dra. Elisa Yumi Nakagawa
Descrição de Casos de Uso (Casos de Uso Textuais) SSC 124: Análise e Projeto Orientados a Objetos Profa. Dra. Elisa Yumi Nakagawa 1 Documentação de Casos de Uso n Notação diagramática: n Diagrama de Casos
Leia maisProjeto Orientado a Objetos
Projeto Orientado a Objetos Conjunto de atividades que têm como objetivo a criação de um modelo orientado a objetos de um sistema de software de acordo com os requisitos especificados Estratégia geral
Leia maisPadrões de Projeto. Conteúdo. Objetivos
Padrões de Projeto Conteúdo O que são Padrões de Projeto? Para que servem? Vantagens/Desvantagens, Pontos Fortes/Fracos Exemplos e Alternativas Objetivos Conhecer diferentes padrões; Entender sua utilidade;
Leia maisCasos de Uso. SSC-121 Engenharia de Software I. Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2012
Casos de Uso SSC-121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2012 1 Definição Um caso de uso representa uma possível utilização do sistema por um ator, que pode ser uma
Leia maisModelagem de Casos de Uso (Parte 1)
Modelagem de Casos de Uso (Parte 1) Introdução (1) Objetivos Principais dos Casos de Uso: Delimitação do contexto de um sistema Documentação e o entendimento dos requisitos Descrição dos requisitos funcionais
Leia maisDo Projeto à Codificação. SSC-526 Análise e Projeto Orientados a Objeto Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2013
Do Projeto à Codificação SSC-526 Análise e Projeto Orientados a Objeto Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2013 1 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos
Leia maisAnálise e Projeto Orientados a Objetos
Análise e Projeto Orientados a Objetos Diagramas de interação Diretoria Acadêmica de Gestão e Tecnologia da Informação Curso de Tecnologia em Análise e Desenvolvimento de Sistemas Introdução Os diagramas
Leia maisIntrodução. Diagramas de Interação. Introdução. Introdução. Introdução. Introdução. Os modelos de análise não respondem a algumas perguntas:
Diagramas de Interação Os modelos de análise não respondem a algumas perguntas: Como as operações do sistema são executadas internamente? A que classes estas operações internas pertencem? Quais objetos
Leia maisDiagramas de Sequência de Sistema e Contratos de Operação
Diagramas de Sequência de Sistema e Contratos de Operação CI163 Projeto de Software Prof. Andrey Ricardo Pimentel Comportamento do Sistema A etapa de análise tem como objetivo definir o comportamento do
Leia maisModulo II Padrões GRASP
Modulo II Padrões GRASP Professores Eduardo Bezerra edubezerra@gmail.com Ismael H F Santos ismael@tecgraf.puc-rio.br April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Ementa Padrões de Projeto
Leia maisIntrodução à Análise e Projeto de Sistemas
Introdução à I. O Que vamos fazer na Disciplina? Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO Tem que saber Análise e Projeto OO (APOO) Isto é, Análise
Leia maisAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas Prof. Dr. Ronaldo C. de Oliveira ronaldo.co@ufu.br www.facom.ufu.br/~ronaldooliveira FACOM - 2018 Diagramas de Interação de Objetos Diagramas de Interação O Diagrama de Interação
Leia maisOrientação a Objetos e Java
Orientação a Objetos e Java Daves Martins davesmartins@yahoo.com.br Mestre em Computação de Alto Desempenho pela UFRJ Especialista em Banco de Dados Analista Web Orientação a Objetos e Java Características
Leia mais4 Conceito de Herança
4 Conceito de Herança Hierarquia de classes e mecanismo de ligação Herança Uma classe pode herdar operações de uma superclasse e as suas operações podem ser herdadas por subclasses. O mecanismo de herança
Leia maisVisibilidade e Diagrama de Classe de Projeto Estudo de Caso Sistema TPV
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Visibilidade e Diagrama de Classe de Projeto Estudo de Caso Sistema
Leia maisUML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos
UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos joao.queiroz@ifrn.edu.br Roteiro A importância da UML para projetar sistemas. Principais características do diagrama de classes e de sequência.
Leia mais15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos
DCC / ICEx / UFMG Pensar Orientado a Objetos Projeto Orientado a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Onde quer que você olhe no mundo real, você vê objetos Pessoas, animais, plantas,
Leia maisModelagem Dinâmica. Toda a ação é designada em termos do fim que procura atingir. Niccolo Maquiavel. O pensamento é o ensaio da ação.
Modelagem Dinâmica Toda a ação é designada em termos do fim que procura atingir. Niccolo Maquiavel O pensamento é o ensaio da ação. Sigmund Freud Modelagem Dinâmica Identifica e modela os aspectos do sistema
Leia maisEngenharia de Software. Projeto de Arquitetura
Engenharia de Software Projeto de Arquitetura O que já vimos? Introdução a Engenharia de Software Processos de Software Desenvolvimento Ágil de Software Engenharia de Requisitos Modelagem de sistemas (outra
Leia maisUNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Modelo Conceitual 879 Projeto e Desenvolvimento de Sistemas de Informação
Leia maisUML Diagramas de Interação
CBSI Curso de Bacharelado em Sistemas de Informação UML Diagramas de Interação Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Análise e Projeto de Sistemas Faculdade de Computação
Leia maisAnálise e Projeto de Software Parte II. Marcos Dósea
Análise e Projeto de Software Parte II Marcos Dósea marcosdosea@gmail.com Agenda Aula III Análise de Software Orientado à Objetos Motivação Marcos Dósea marcosdosea@gmail.com O que é análise e projeto?
Leia maisMODELAGEM DE SISTEMAS Unidade 4 Modelo de Classes de Projeto. Luiz Leão
Unidade 4 Modelo de Classes de Projeto Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático Definição da Visibilidade entre Objetos Adição de Operações às Classes de Projeto Adição
Leia maisDCC004 - Algoritmos e Estruturas de Dados II
Conceito de especificação de software Renato Martins Email: renato.martins@dcc.ufmg.br https://www.dcc.ufmg.br/~renato.martins/courses/dcc004 Material adaptado de PDS2 - Douglas Macharet e Flávio Figueiredo
Leia maisDiagramas de Classes. ESII Profª. Andressa Falcade URI Santiago
Diagramas de Classes Conceitos Básicos O caso de uso fornece uma perspectiva do sistema de um ponto de vista externo (do ator) Internamente os objetos colaboram para atender às funcionalidades do sistema
Leia maisPROJETO DE ARQUITETURA (PARTE 2)
PROJETO DE ARQUITETURA (PARTE 2) Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... 5ª Lista de Exercícios Já está disponível no site a 5ª Lista de Exercícios Entrega: dia
Leia maisLinguagem de Programação I Apresentação da Disciplina
Linguagem de Programação I Apresentação da Disciplina Apresentação da Disciplina Conteúdo: 1) Orientação a Objetos - Características da OO - Reutilização de código 2) Introdução à Linguagem Java - Histórico
Leia maisModelos de Sistemas Casos de Uso
Modelos de Sistemas Casos de Uso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Casos de Uso Objetivos Principais dos Casos de Uso: Delimitação do contexto de
Leia maisO Processo Unificado: Workflow de Análise. Graduação em Informática Profa. Dra. Itana Maria de Souza Gimenes 2009
O Processo Unificado: Workflow de Análise Graduação em Informática Profa. Dra. Itana Maria de Souza Gimenes 2009 Workflow de Análise Objetivos da análise: manter uma especificação precisa dos requisitos
Leia maisPROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001
PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO Projeto de Programas PPR0001 QUALIDADE DO PROJETO 2 3 Qualidade do Projeto de Software Modularidade: gerar particionamento em elementos que executam funções
Leia maisProjeto de software Estrutura do software e arquitetura SWEBOK
Projeto de software Estrutura do software e arquitetura SWEBOK SWEBOK Design Patterns Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas da engenharia Design
Leia maisDiagramas de Classes e O Paradigma da Orientação a Objetos usando UML. Prof. Ricardo A. Ramos
Diagramas de Classes e O Paradigma da Orientação a Objetos usando UML Prof. Ricardo A. Ramos Engenharia de Software II 207. 04/07/207 UML Unified Modeling Language É uma linguagem para especificação, construção,
Leia maisPanorama da notação UML
Panorama da notação UML A notação UML (Unified Modeling Language linguagem de modelagem unificada) evoluiu desde que foi adotada a primeira vez como um padrão em 1997. Uma revisão maior para o padrão foi
Leia maisEngenharia de Software
Engenharia de Software Design Principles Representando SW em UML OO em C Pattens úteis para embedded Rodrigo M A Almeida Design Principles Design Principles são guias para decompor as funcionalidades e
Leia maisIntrodução ao Java. Prof. Herbert Rausch Fernandes
Introdução ao Java Prof. Herbert Rausch Fernandes Orientação a Objetos Programação Orientada por Objetos: é a construção de sistemas de software como uma coleção estruturada de implementações de tipos
Leia maisInterações entre objetos
Interações entre objetos 1 Interações! Interações mostram os aspectos dinâmicos de um sistema, enfatizando a troca de mensagens entre objetos! Dois diagramas podem ser usados para modelar as interações:
Leia maisIntrodução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.
Diagramas UML Classe, Seqüência e Atividades Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 15 de maio
Leia maisUniversidade de São Paulo, Instituto de Ciências Matemáticas e de Computação
Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação CASOS DE USO SSC 621: Análise e Projeto Orientados a Objetos Prof. Dr. Lucas Bueno R. Oliveira 2º Semestre 2015 DEFINIÇÃO Um
Leia maisProgramação Orientada a Objetos
Curso Profissional de Gestão e Programação de Sistemas Informáticos Disciplina: Programação e Sistemas de Informação Programação Orientada a Objetos Módulos 9/10/11 POO 2016/2017 História A OO surgiu no
Leia maisGeneral Responsibility Assignment Software Patterns
GRASP General Responsibility Assignment Software Patterns Os padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto GRASP Qual é a conexão entre Responsabilidades,
Leia maisDiagramas de Sequência do Sistema. SSC 124: Análise e Projeto Orientados a Objetos Profa. Dra. Elisa Yumi Nakagawa
Diagramas de Sequêcia do Sistema SSC 124: Aálise e Projeto Orietados a Objetos Profa. Dra. Elisa Yumi Nakagawa 1 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos de Uso Emprestar
Leia maisProgramação Orientada a Objectos - P. Prata, P. Fazendeiro. Hierarquia de classes e mecanismo de ligação
4 Conceito de Herança Hierarquia de classes e mecanismo de ligação Herança Uma classe pode herdar operações de uma superclasse e as suas operações podem ser herdadas por subclasses. O mecanismo de herança
Leia mais15/04/2013. Outro Diagrama de Classes. Primeiro Diagrama de Classes. Diagrama de Classes. Atributos. Eduardo Figueiredo
DCC / ICEx / UFMG Primeiro Diagrama de Classes Diagrama de Classes Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Professor Aluno matricula Outro Diagrama de Classes Diagrama de Classes Serve de
Leia maisDIAGRAMAS DE CLASSE UML
DIAGRAMAS DE CLASSE UML Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Calendário de Reposições Aula 1: 27/10/2017, 8h-10h, Sala 8 Aula 2: A verificar Aula 3: A verificar
Leia mais3 Arquitetura para a Coordenação e a Composição de Artefatos de Software
Uma Arquitetura para a Coordenação e a de Artefatos de 23 3 Arquitetura para a Coordenação e a de Artefatos de Resumo Este capítulo apresenta a arquitetura ACCA, que é a parte central deste trabalho. A
Leia maisPadrões de Projeto de Software
Padrões de Projeto de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Introdução O que é? Como descrever? Principais Padrões de Projetos Unidade 2 Padrões GoF PADRÕES CRIAÇÃO Abstract Factory
Leia maisINSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE
1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE Nickerson Fonseca Ferreira nickerson.ferreira@ifrn.edu.br O que é?? 2 A UML
Leia maisRequisitos de sistemas
Requisitos de sistemas Unidade III - Casos de Uso Identificação de casos de uso Conceitos de orientação a objetos Modelagem do diagrama de classes e casos de uso 1 Casos de uso CONCEITO Especifica o comportamento
Leia mais2
ANÁLISE DE SISTEMAS (processo de desenvolvimento de sistemas) por Antônio Maurício Pitangueira 1 2 Levantamento de requisitos Análise de requisitos Projeto Implementação Testes Implantação Foco da disciplina
Leia maisAnálise e Projeto Orientados a Objetos
Análise e Projeto Orientados a Objetos Modelagem conceitual do domínio Diretoria Acadêmica de Gestão e Tecnologia da Informação Introdução A modelagem do domínio está relacionada à descoberta das informações
Leia maisAnálise e projeto de sistemas
Análise e projeto de sistemas Conteúdo: UML O processo de desenvolvimento de software Prof. Patrícia Lucas A linguagem de modelagem unificada (UML) A UML teve origem em uma tentativa de se unificar os
Leia maisUNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 15 PROFª BRUNO CALEGARO
UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 15 PROFª BRUNO CALEGARO Santa Maria, 08 de Novembro de 2013. Contextualização Nas próximas aula iremos começar a modelar e projetar sistemas
Leia maisCiência da Computação. Análise e Projeto Orientado a Objetos UML. Anderson Belgamo
Ciência da Computação Análise e Projeto Orientado a Objetos UML Anderson Belgamo 1 Evolução do Software O rápido crescimento da capacidade computacional das máquinas resultou na demanda por sistemas de
Leia maisTema da aula Introdução ao paradigma de programação: Orientado a Objetos
Profa. Juliana Santiago Teixeira Disciplina: Programação Orientada a Objetos I Tema da aula Introdução ao paradigma de programação: Orientado a Objetos Paradigma Paradigma é a filosofia adotada na construção
Leia maisProgramação Orientada a Objeto
Programação Orientada a Objeto Prof. Esp. Thiago S F Carvalho Faculdades Integradas de Diamantino 2016 Caravalho, T.S.F. (FID) POO 2016 1 / 44 Breve revisão Conteúdo 1 Breve revisão 2 Mais sobre classes
Leia maisUML (Unified Modelling Language)
UML (Unified Modelling Language) Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Booch, G. et al. The Unified Modeling Language User Guide
Leia maisOs princípios do desenho orientado a objetos
Os princípios do desenho orientado a objetos Os princípios do desenho orientado a objetos Encapsulamento e congeneridade Domínios, grau de dependência e coesão Os perigos da herança e do polimorfismo Encapsulamento
Leia maisMODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro
MODELAGEM DE SISTEMAS Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Introdução Modelagem de Sistemas: A modelagem de um sistema auxilia o analista a entender a funcionalidade
Leia maisUniversidade Federal de Uberlândia Faculdade de Computação. Linguagem C: Operadores relacionais e lógicos estruturas condicionais If...
Universidade Federal de Uberlândia Faculdade de Computação Linguagem C: Operadores relacionais e lógicos estruturas condicionais If... Else Switch Prof. Renato Pimentel 1 Operações relacionais Operações
Leia maisCapítulo 2. Orientação a Objetos
Capítulo 2 Orientação a Objetos Princípios da Orientação a Objetos Os princípios da orientação a objetos afetam todo o processo de desenvolvimento de software: Seres humanos pensam em termos de substantivos
Leia maisClasses de Projeto. Prof. Anderson Cavalcanti UFRN-CT-DCA
Classes de Projeto Prof. Anderson Cavalcanti UFRN-CT-DCA Linhas Gerais sobre as Classes de Projeto Especificação de Classes de Projeto Especificação de classes de fronteira Responsáveis pela interação
Leia maisFrameworks. SSC-526 Análise e Projeto Orientados a Objeto Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2013
Frameworks SSC-526 Análise e Projeto Orientados a Objeto Profa. Dra. Elisa Yumi Nakagawa 2º semestre de 2013 1 Frameworks Definições: Aplicação semi-completa reutilizável que, quando especializada, produz
Leia maisDiagramas de Sequência e Contrato das Operações
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de informação Comportamento
Leia maisAnálise de Requisitos
Análise de Requisitos Prof.ª: Érika A. Barrado Analisar x Projetar Análise: significa investigar, descobrir ou desvendar algo; Consiste em encontrar o conjunto de requisitos para um dado software; Definida
Leia maisUML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva
UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades
Leia mais