ELABORAÇÃO. GRASP General Responsibility Assignment Software Patterns. Core of OODesign. Artefactos de input para OOD

Tamanho: px
Começar a partir da página:

Download "ELABORAÇÃO. GRASP General Responsibility Assignment Software Patterns. Core of OODesign. Artefactos de input para OOD"

Transcrição

1 Core of OODesign ELABORAÇÃO Após identificar os requisitos e desenhar o modelo de domínio, a seguir adicionar métodos às classes de software e definir as mensagens entre os objectos para dar resposta aos requisitos A ferramenta de Desenho (Design) crítica para o desenvolvimento de software, é uma mente bem educada nos princípios de Design (não é a UML ou outra tecnologia qualquer) Artefactos de input para OOD Imagine se que o cenário do exemplo do NewPOS é o seguinte, nesta altura. Nota: Nem todos os artefactos são necessários, pois no UP tudo é opcional. GRASP General Responsibility Assignment Software Patterns A primeira workshop de levantamento de requisitos, com duração de dois dias, está terminada Três dos vinte casos de uso (aqueles que são arquitecturalmente relevantes e de alto valor de negócio), foram analisados em detalhe, incluindo, claro, o use case do processo de venda. Experiências de programação resolveram algumas questões técnicas relevantes como sejam, se o UI Java Swing trabalhava num monitor de touch screen. O arquitecto chefe e de negócio concorda em implementar e testar alguns cenários do Processo de Venda na primeira iteração, timeboxed, de três semanas Outros artefactos foram iniciados: Especificações Suplementares, Glossário e o Modelo de Domínio. O arquitecto chefe desenhou algumas ideias para a arquitectura lógica de larga escala, usando diagramas de package em UML. Isto é parte do Modelo de Desenho no UP.

2 Cashier Process Sale Artefactos de input para OOD Relações entre artefactos no UP Sample UP Artifact Relationships O use case em texto define o comportamento visível, que os objectos de software devem suportar osobjectos são desenhados para realizar (implementar) os use cases. No UP, este desenho OO é chamado realização de caso da uso. Os Diagramas de Sequencia do Sistema identificam as mensagens de operação do sistema, que são as mensagens iniciais nos diagramas de interacção dos objectos em colaboração Os contratos de operação podem complementar os casos de uso em texto, para clarificar o que é que os objectos de software devem efectuar numa operação do sistema. As pós condições definem objectivos detalhados A Especificação Suplementar define os requisitos não funcionais (URPS+), que os objectos devem suportar O glossário clarifica parâmetros ou dados provenientes do nível de UI, dados a passarem para a BD e requisitos de validação ou lógica específica, tal como formatos legais e validação para UPCs dos produtos O Modelo de Domínio sugere alguns nomes e atributos de objectos no nível de domínio da arquitectura de software Business Modeling Requirements inspiration for names of some software domain objects starting events to design for, and detailed postcondition to satisfy Design Domain Model Sale..* Sales... LineItem date quantity Use-Case Model Process Sale use. Customer Supplementary case arrives Specification names Cashier enters item identifier. non-functional functional requirements Use Case Diagram Use Case Text requirements that must be domain rules ideas for system realized by the postconditions events the objects : System Glossary Operation: : Cashier enteritem( ) make system NewSale() Post-conditions: operations enteritem -... (id, quantity) item details, formats, Operation Contracts System Sequence Diagrams validation Design Model : Register : ProductCatalog : Sale enteritem (itemid, quantity) d = getproductdescription(itemid) addlineitem( d, quantity ) Register ProductCatalog makenewsale() * getproductdescription() enteritem() Actividades do Desenho de Objectos Responsability Driven Design (RDD) Sai o analista Entra o Modelador Desenhador Na abordagem RDD os objectos têm responsabilidades (uma abstracção do que eles fazem) Começar imediatamente t o desenvolvimento (idealmente utilizando a abordagem Teste First Development) Começar outras técnicas de modelação como por exemplo Cartas CRC Começar alguma modelação UML dos objectos do desenho Desenhar Diagramas de Interacção (modelo dinâmico) ~ dia Diagramas de Classe (modelo estático) Aplicar princípios ou padrões GRASP e GoF durante o desenho e codificação A abordagem a modelação OOD é baseada na metáfora Responsability Driven Design (RDD) pensar como atribuir responsabilidades aos objectos As responsabilidades são atribuídas a classes de objectos durante o desenho dos objectos RDD é uma metáfora para ajudar o processo de desenho de software OO. Pensar em objectos de software de forma similar em como pensamos em pessoas com responsabilidades que colaboram com outras pessoas para executarem o seu trabalho Uma responsabilidade não é o mesmo que um método, é uma abstracção, mas os métodos implementam responsabilidades 2

3 Tipos de Responsabilidades RDD >> Colaboração As responsabilidades de fazer, de um objecto incluem: Fazer algo ele próprio, tal como criar um objecto ou efectuar um cálculo Iniciar acções noutros objectos Controlar e coordenar actividades noutros objectos A abordagem RDD inclui a ideia de colaboração. As responsabilidades são implementadas através de métodos, que actuam sozinhos ou colaboram com outros métodos e objectos As responsabilidades de saber de um objecto incluem: Ter conhecimento de dados privados encapsulados Ter conhecimento de objectos relacionados Ter conhecimento de coisas que pode derivar ou calcular Ex.: Uma Venda é responsável por criar LinhasDeVenda (um fazer ) Uma Venda é responsável por saber o seu total (um saber ) Ex: A classe Venda pode definir um ou mais métodos para saber o seu total, por exemplo um método chamado GetTotal. Para dar resposta a essa responsabilidade a Venda pode colaborar com outros objectos, tal como enviar uma mensagem GetSubtotal para cada objecto LinhaDeVenda a solicitar o seu subtotal. Guidelines RDD GRASP Para objectos do domínio do software, o Modelo de Domínio é uma fonte de inspiração para as responsabilidades do saber. Ex: Uma Venda no MD tem um atributo datahora. É natural que a classe de software saiba a sua data e hora. A tradução de responsabilidades em classes e métodos é influenciada pela granularidade da responsabilidade Grandes responsabilidades podem incluir centenas de classes e métodos GRASP: General Responsibility Assignment Software Patterns GRASP é uma abordagem metodológica ao Desenho OO Os princípios ou padrões subjacentes ao GRASP são um auxiliar para perceber o essencial do desenho de objectos e aplicar o raciocínio de desenho de uma forma metodológica, racional e perceptível. A abordagem GRASP é baseada em padrões de atribuição de responsabilidades Pequenas responsabilidades podem incluir apenas um método 3

4 Responsabilidades >> GRASP >> UML Padrões (Patterns) O que são? Podemos pensar sobre as responsabilidades a atribuir, ou seja aplicar o GRASP, durante várias fases, nomeadamente, na codificação e na modelação Programadores e arquitectos de software experientes em OO foram criando um conjunto de princípios gerais e soluções idiomáticas para se suportarem na criação de software Em UML, no desenho dos Diagramas de Interacção são o meio para considerar estas responsabilidades Quando desenhamos os DI, estamos a decidir sobre quais as responsabilidades a atribuiraa cada objecto Estes princípios que são designados por padrões de desenho são apresentados de uma forma estruturada que descreve o problema, a solução e têm um nome Muitos padrões, dada um tipo de problema, orientam na atribuição das responsabilidades Exemplo: GRASP >> UML Padrões >> Estrutura >> Exemplo :: Venda Sale EfectuarPagamento(valorEntregue) makepayment(cashtendered) Create(valorEntregue) create(cashtendered) : Pagamento Payment Nome do Padrão: Problema: Information Expert Qual é o principio básico para atribuição de responsabilidades a objectos abstract, Implica que implies o objecto Sale Venda objects tem ahave a responsibility responsabilidade s to de create criar e Pagamentos Payments Solução: Atribuir a responsabilidade a uma classe que tenha a informação para dar resposta a essa responsabilidade 4

5 Padrões GRASP >> CREATOR Creator >> Exemplo Nome do Padrão: Creator Problema: Quem deve ser responsável por criar uma nova instanciade umaclasse? A classe Venda contém (na realidade agrega) muitos objectos LinhasDeVenda. O padrão Creator sugere por esta via que Venda é um bom candidato para ter a responsabilidade de criar as instâncias i LinhaDeVenda Solução: Atribuir à classe B a responsabilidade para criar a instância da classe A, se uma as seguintes situações for verdadeira (quantas mais melhor) B contém ou agrega compositamente A B armazena A B usa A de forma próxima B tem os dados de inicialização de A, que lhe serão passados quando for criado. Assim B é um Expert em relação a cria A Esta atribuição faz com que o método MakeLinhaDeVenda seja definido na Venda Notar que as responsabilidades são atribuídas enquanto se desenha o DI. A secção dos métodos nas classes do DC, podem depois sumarizar as responsabilidades atribuídas Creator >> Exemplo Creator >> Exemplo Exemplo: Quem deve responsável por criar a instância SalesLineItem no projecto NewPOS? O DI seria então: Considerar o modelo de domínio parcial que foi desenhado: : Register : Sale Sale time makelineitem(quantity) create(quantity) : SalesLineItem Contains Sales LineItem quantity..* * Described-by Product Description description price itemid 5

6 Creator >> Orientações Padrões GRASP >> Expert O Creator orienta a atribuir as responsabilidades relacionadas com a criação dos objectos A escolha do Creator deve obedecer a critérios de low coupling (baixo acoplamento) Composito, agrega Parte, Contentor contém Conteúdo e Gravador (Recorder) grava Gravação. Estas são relações muito comuns entres classes num DI. O Creator sugere que as classes Composito, Contentor ou Gravador são boas candidatas para assumirem a responsabilidade de Criarem a coisa contida ou gravada Nome do Padrão: Information Expert (or Expert) Problema: Qual é o principio geral para atribuição de responsabilidades a objectos? Solução: Atribuir a responsabilidade ao Information Expert A classe que tem a informação necessária para satisfazer a responsabilidade Creator >> Orientações Muitas vezes identificamos o Creator, procurando a classe que tem os dados de inicialização do que são passados durante a criação (Expert pattern) Ex.: A instância pagamento quando e criada necessita de ser inicializada com o total da Venda. Assim sendo que classe é a melhor Candidata para criar a instância Pagamento? É a Venda Quando a criação requer um esforço significativo de complexidade, como por exemplo a criação condicional de instâncias de uma família de classes similares baseadas numa qualquer propriedade externa, é aconselhável delegar a criação em classes auxiliares chamadas Concrete Factory ou Abstract Factory Expert >> Exemplo Exemplo: Quem deve responsável por saber o grande total de uma Venda? Considerar o modelo de domínio parcial que foi desenhado: time Sale Sales LineItem quantity Contains..* * Described-by Product Description description price itemid Pelo principio Information Expert devemos procura a classe que tem a informação necessária que é necessária para calcular o Total 6

7 Expert >> Exemplo Expert >> Exemplo Onde devemos procurar as classes que tem a informação necessária? No Modelo de Domínio ou no Modelo de Desenho? Se existirem i classes relevantes no modelo dl de domínio começar por aí Se não, procurar no modelo de desenho e tentar usar ou expandir as suas representações para inspirar a criação de classes reais 2 ) Mas para calcular os subtotais precisamos ainda da informação LinhaDeVenda.Quantidade e Descriçãoproduto.preço A Linha de venda sabe a sua quantidade e está associada à DescriçãoProduto. Assimpelo Expert a LinhaDeVenda calcula o subtotal ) Neste exemplo podemos olhar para o MD e talvez considerar que a classe Venda preenche os requisitos necessários. Assim criamos uma classe similar Venda no Modelo Desenho atribuirmos lhe a responsabilidade de saber o total expresso pelo método GetTotal t = GetTotal *: st = GetSubtotal t gettotal *: st getsubtotal linhasprodutos[ lineitems[ i i ] : : : Venda Sale SalesLineItem LinhaDeVenda : Sale Venda time datahora gettotal() : SalesLineItem LinhaDeVenda quantity quantidade New Novo method Método getsubtotal() GetSubtotal( ) O DI será então: Expert >> Exemplo Expert >> Exemplo 3 ) Mas para satisfazer a responsabilidade de calcular o subtotal a classe LinhaDeVenda precisa de saber o preço t = GetTotal) gettotal t E a classe de software no MCD será: ::Sale Venda Assim a classe DescriçãoProduto, é um InformationExpert em disponibilizar e saber o preço. t = GetTotal *: st = GetSubtotal t gettotal *: st getsubtotal linhasprodutos[ lineitems[ i i ] : : : Venda Sale SalesLineItem LinhaDeVenda..: : p p = := GetPreço( getprice() ) e : Sale Venda :Product : DescriçaoProduto Description New Novo method método time datahora gettotal() : Sale Venda time datahora : SalesLineItem LinhaDeVenda quantity quantidade Product DescriçaoProduto Description description descrição price preço itemid produtoid gettotal() getsubtotal() GetSubtotal( ) New Novo method Método getprice() GetPreço( ) 7

8 Expert >> Resumo Exemplo Para satisfazer a responsabilidade de saber e disponibilizar o total da venda, atribuímos três responsabilidades a três classes de software: Padrões GRASP >> Low Coupling Nome do Padrão: Low Coupling Problema: Como suportar baixa dependência, baixo impacto à mudança e aumentar a reutilização? Classe de Desenho Venda LinhaDeVenda DescriçãoProduto Responsabilidade Sabe o total da venda Sabe o subtotal de uma linha Sabe o preço do produto Solução: Atribuir a responsabilidade de forma a que o acoplamento se mantenha baixo. Usar este princípio na avaliação de alternativas. Nota: Decidimos atribuição das responsabilidades ao desenharmos um DI. E de seguida fizemos reflectir os métodos relativos a essas responsabilidades no DCS Creator >> Orientações Padrões GRASP >> Low Coupling O Expert expressa a intuição de que os objectos fazem coisas relacionadas com a informação que têm A satisfação de uma responsabilidade requer muitas vezes informação que está dispersa por diferentes classes de objectos, o que implica que muitosinformation Expert parciais colaborem nessa tarefa Em algumas situações o Expert mais óbvio, não é a melhor solução devido a problemas com o acoplamento e coesão (princípios a ver) E.g.: Que classe é responsável por gravar uma venda na base de dados? Se for a venda, como seria mais óbvio, a coesão baixa pois a classe passa a estar focada no que tem de fazer e por outro lado o acoplamento aumenta, pois passa a estar acoplada a serviços técnicos de base de dados em vez de estar acoplada apenas a outros objectos no nível de domínio dos objectos de software Acoplamento é uma medida para medir quão forte um elemento está ligado, tem conhecimento de ou depende de outros elementos Uma classe de alto acoplamento depende de muitas outras o que é indesejável e algumas delas sofrem dos seguintes problemas: Alterações locais forçadas devido a alterações em classes relacionadas Difíceis de perceber se isoladas Difíceis de utilizar porque requerem a presença adicional das classes das quais são dependentes 8

9 Low Coupling >> Exemplo Exemplo: Considerar o seguinte DC parcial do projecto NewPOS Pagamento Registadora Venda Se se pretender criar uma instância de Pagamentos e associá la com a Venda correspondente, qual deve ser a classe responsável por isso? Low Coupling >> Exemplo Qual das soluções anteriores apresenta menor acoplamento? Em ambas existe acoplamento da Venda a Pagamento, mas no segundo caso ao atribuirmos à Venda a responsabilidade de criar o Pagamento estamos a diminuir o acoplamento pois a Registadora deixa de estar acoplada a Pagamento. No domínio do mundo real, é a classe Registadora que grava um pagamento, o padrão Creator sugere a classe Registadora como uma candidata para criar a instância Pagamento. De seguida a Registadora pode enviar uma mensagem à classe Venda com o novo pagamento como parametro Low Coupling >> Exemplo EfectuarPagamento( ) : Registadora : Create( ) 2: Addpagamento(p) p : Pagamento : Venda Esta atribuição de responsabilidade acopla a classe registadora à classe Pagamento Outra via alternativa seria: EfectuarPagamento( ) EfectuarPagamento( ) : Registadora : Venda Low Coupling >> Orientações Na prática o nível de acoplamento não pode ser considerado de forma isolada de outros padrões (princípios) como por exemplo Expert ou High Cohesion. Ainda assim é um factor a considerar na melhoria do desenho. O padrão Low Coupling deve estar presente em todas as decisões de desenho. É um objectivo a perseguir constantemente. É um princípio de avaliação a usar em todas as decisões do desenho. :Create( ) Pagamento 9

10 Low Coupling >> Orientações Linguagens de programação como Java, C++ ou C# podem formar vários acoplamentos TypeX para TypeY dos tipos: TypeX tem um atributo que se refere a uma instância do TypeY ou mesmo de TypeY Um objecto TypeX chama serviços de um objecto TypeY TypeX tem um método que referencia uma instância do TypeY, ou mesmo de TypeY. Tipicamente isto inclui um parâmetro ou variável local do TypeY ou um objecto retornado de uma mensagem, que é deumainstância i do TypeY TypeX é uma subclasse directa ou indirecta de TypeY TypeY é uma interface e TypeX implementa essa interface Low Coupling >> Orientações O caso extremo de low coupling é nenhum acoplamento!! Mas isso é contra o paradigma da OO, que diz que este é um sistema de objectos colaborante que comunicam entre si por mensagens. A virtude está numa avaliação constante dos vários princípios. Low Coupling >> Orientações Uma subclasse é fortemente acoplada à sua superclasse. Sempre que se derivar de uma superclasse deve ter se em atenção o forte acoplamento Se por exemplo existem objectos que devem ser guardados persistentemente numa BD, pode se optar por utilizar o padrão de desenho e criar uma superclasse PersistentObject da qual todas as outras derivam. A desvantagem é que acopla objectos do domínio a um serviço técnico particular e mistura diferentes preocupações específicas das várias arquitecturas, mas tem a vantagem de uma hereditariedade automática para o comportamento persistente. Padrões GRASP >> High Cohesion Nome do Padrão: High Cohesion Problema: Como manter os objectos focados, compreensíveis e geriveis e como efeito colateral suportarem baixo acoplamento? Solução: Atribuir a responsabilidade de forma a que a coesão se mantenha o mais alta possível. Utilizar este padrão para avaliar alternativas. Nota: Em termos de desenho de objectos, a coesão é uma medida de quão fortemente relacionadas e focadas as responsabilidades de um elemento são 0

11 Padrões GRASP >> High Cohesion Uma classe com baixa coesão faz muitas coisas não relacionadas umas com as outras ou faz muito trabalho. Tais classes são indesejáveis, elas têm os seguintes problemas: Difíceis de compreender Difíceis de reutilizar Difíceis de manter Delicadas. São constantemente afectadas pela mudança High Cohesion >> Exemplo Na opção ) a atribuição de responsabilidades coloca a responsabilidade de efectuar um pagamento na Registadora. A registadora está envolvida em parte da responsabilidade de satisfazer a operação do sistema EfectuarPagamento Este exemplo por si só é aceitável, mas se continuarmos a fazer com que a registadora seja responsável por efectuar a maior parte do trabalho relacionado com operações do sistema, ficará cada vez mais pesado e torna se não coeso. Ao delegar se o pagamento na Venda está se a suportar uma maior coesão na registadora. Por ser mais coeso e com menos acoplamento a opção 2 é melhor ) Low Coupling >> Exemplo Vejamos novamente o exemplo usado para estudar o Low Coupling e vamos analisá lo do ponto de vista do High Cohesion As alternativas são: EfectuarPagamento( ) : Registadora : Create( ) p : Pagamento High Cohesion >> Orientações A alta coesão tem uma analogia na vida real: É facilmente observável que se uma pessoa tiver demasiadas responsabilidades não relacionadas, principalmente aquelas que poderiam facilmente ser delegadas noutros, essa pessoa torna se ineficaz. 2) 2: Addpagamento(p) EfectuarPagamento( ) EfectuarPagamento( ) : Venda : Registadora : Venda. :Create( ) Pagamento Um dos princípios clássicos do desenvolvimento de software éfazê lo com a maior modularidade possível. A coesão e o baixo acoplamento promovem a modularidade, pois: A modularidade é a propriedade de um sistema poder ser decomposto num conjunto de módulos coesos e de baixo acoplamento [Booch94]

UML & 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 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

Padrões de projeto 1

Padrões de projeto 1 Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois

Leia mais

ARQUITECTURAS DE SOFTWARE

ARQUITECTURAS DE SOFTWARE ARQUITECTURAS DE SOFTWARE AULAS Nº 8 e 9 7-21/12/2007 F. Mário Martins Case Studies: Ligação das partes Use Case Diagram Use Case Specification Passo 1: ---------- Passo 2: ---------- Passo 3: ----------

Leia mais

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS.

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS. PADRÕES DE SOFTWARE 1 Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade Grupo de Padrões de Software da UECE (GPS.UECE) Julho-2009 CONTEÚDO Introdução aos Padrões de Software O quê são padrões?

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

Leia mais

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos Programação Avançada Padrões de Projeto de Software 1 Fonte: Oswaldo B. Peres e K19 Treinamentos Introdução Projetar software OO reusável e de boa qualidade é uma tarefa difícil; Para realizar essa tarefa

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

Desenho de Software. Desenho de Software 1

Desenho de Software. Desenho de Software 1 Desenho de Software Desenho de Software 1 Sumário Caracterização Conceitos fundamentais Desenho funcional e desenho OO Qualidades Desenho de Software 2 Bibliografia Pfleeger, Capítulo 6 Design the Modules

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

UML Visão Geral. Índice. Introdução. Diagramas. Modelos e diagramas. Elementos de modelação. Referências

UML Visão Geral. Índice. Introdução. Diagramas. Modelos e diagramas. Elementos de modelação. Referências UML Visão Geral 1 Índice Introdução O que é a UML? Valor da UML Origens da UML Parceiros da UML Modelos e diagramas Elementos de modelação Diagramas Diagrama de casos de utilização Diagrama de classes

Leia mais

Padrão Básico de Projeto: Herança versus Composição

Padrão Básico de Projeto: Herança versus Composição Padrão Básico de Projeto: Herança versus Composição Composição e Herança Composição e herança são dois mecanismos para reutilizar funcionalidade Alguns anos atrás (e na cabeça de alguns programadores ainda!),

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Maciaszek L.A. and Liong B.L. (2005), Practical Software Engineering Addison Wesley http://www.comp.mq.edu.au/books/pse/index.htm http://www.comp.lancs.ac.uk/computing/resources/ians/se7/index.ht

Leia mais

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento Desenvolvimento Iterativo Esta abordagem ao desenvolvimento assegura que o sistema cresce de forma incremental assegura que a complexidade se mantém controlada permite ainda obter rápido feedback de várias

Leia mais

Projeto Detalhado. Projeto Detalhado. Modelo de decomposição em módulos. Passos de Projeto. Análise e Projeto OO. Análise e Projeto OO

Projeto Detalhado. Projeto Detalhado. Modelo de decomposição em módulos. Passos de Projeto. Análise e Projeto OO. Análise e Projeto OO Projeto Detalhado Projeto Detalhado Projeto Orientado a Objetos Introdução ao projeto detalhado OO Construindo os digramas de interação Padrões GRASP Diagrama de Classes Perspectivas de Projeto Passos

Leia mais

Neste momento a gestão dos automóveis, de grupos de automóveis e de manutenção não são consideradas relevantes para serem suportadas pelo sistema.

Neste momento a gestão dos automóveis, de grupos de automóveis e de manutenção não são consideradas relevantes para serem suportadas pelo sistema. Caso 1 Rent-a-car 1 Enunciado Pretende-se desenvolver um software de suporte a diversas actividades duma empresa de aluguer de automóveis. Este software deve permitir registar contratos de aluguer, entregas

Leia mais

Diagrama de Classes. Diagrama de Classes. Diagramas de Classe. POST Criando Diagramas de Classe. Como construir (2)

Diagrama de Classes. Diagrama de Classes. Diagramas de Classe. POST Criando Diagramas de Classe. Como construir (2) Diagrama de Classes Diagrama de Classes Modelo de classes de especificação Perspectiva de Projeto Ilustra as especificações de software para as classes e interfaces do sistema. É obtido através da adição

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

Iteração 2 Design inicial

Iteração 2 Design inicial Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Engenharia de Software Iteração 2 Design inicial Projecto: FX-Center Grupo: BEDS David Pacheco (nº 32665) Cesário Lucas

Leia mais

1Introdução Helder da Rocha (helder@acm.org)

1Introdução Helder da Rocha (helder@acm.org) J930 Padrões Projeto de 1Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas

Leia mais

Elsa Cardoso, DCTI - ISCTE

Elsa Cardoso, DCTI - ISCTE Elsa Cardoso, DCTI - ISCTE 25 Maio 2004 elsa.cardoso@iscte.pt Sumário Perspectiva de Desenho do Sistema: Diagrama de classes numa perspectiva de Desenho: Estereótipos Relação de Dependência Relação de

Leia mais

USE CASES: continuação

USE CASES: continuação USE CASES: continuação Balcão de Companhia Aérea Fazer Check-in de Passageiro Funcionário Inserir Reserva de Voo Cancelar Reserva de Voo Os primeiros diagramas de Use Case (DUC) de um Sistema, descrevem

Leia mais

Programação Orientada a Objetos. Padrões de Criação

Programação Orientada a Objetos. Padrões de Criação Programação Orientada a Objetos Padrões de Criação Cristiano Lehrer, M.Sc. Objetivos Apresentar cada um dos 23 padrões clássicos descrevendo: O problema que solucionam. A solução. Diagramas UML (Unified

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Unified Software Development Process

Unified Software Development Process 59/170 Unified Software Development Process Sumário Breve história do Unified Process O Unified Process O ciclo de vida do Unified Process O RUP (Rational Unified Process) 60/170 Breve História do Unified

Leia mais

J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org)

J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org) Padrões de J930 Projeto Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas

Leia mais

OCL: Object Constraint Language

OCL: Object Constraint Language OCL: Amílcar Domingos Rodrigues Santy Fernandes, Girson César Silva Monteiro, Rui Sá Guerra, Simão Castro Faculdade de Engenharia da Universidade Do Porto, Rua Dr. Roberto Frias, s/n 4200-465 Porto, Portugal

Leia mais

Processo de Desenvolvimento de Software. Engenharia de Software. nelmarpg@yahoo.com.br

Processo de Desenvolvimento de Software. Engenharia de Software. nelmarpg@yahoo.com.br Processo de Desenvolvimento de Software nelmarpg@yahoo.com.br 1 Objetivos Contextualizar Análise e Projeto de software dentro de uma metodologia de desenvolvimento (um processo de desenvolvimento de software)

Leia mais

ARQUITECTURAS DE SOFTWARE

ARQUITECTURAS DE SOFTWARE ARQUITECTURAS DE SOFTWARE AULAS Nº 5, 6 e 7 16-23-30/11/2007 F. Mário Martins Ligação das partes Use Case Diagram Use Case Specification Passo 1: ---------- Passo 2: ---------- Passo 3: ---------- Domain

Leia mais

De Arte a Ciência: Regras para o Desenho de Software

De Arte a Ciência: Regras para o Desenho de Software De Arte a Ciência: Regras para o Desenho de Software Neste artigo é apresentado um conjunto de regras de desenho um padrão de desenho universal associado ao princípio fundamental e aos requisitos axiomáticos.

Leia mais

Requisitos e Modelação

Requisitos e Modelação Requisitos e Modelação combinação essencial para melhorar o processo de desenvolvimento de software Class4 -End1 -End2 Class1 * * System Actor1 * -End3 -End5 -End7 * Actor2 UseCase1 -End4 * UseCase2 -End6

Leia mais

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

Programa do Módulo 2. Fundações do Modelo Objeto

Programa do Módulo 2. Fundações do Modelo Objeto 2.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Processo Unificado (RUP) Fundações do Modelo Objeto 2.2 Programação Orientada a Objetos: é um método de

Leia mais

O Processo de Desenvolvimento de Software

O Processo de Desenvolvimento de Software O Processo de Desenvolvimento de Software Objetivos Contextualizar Análise e Projeto de software dentro de uma metodologia de desenvolvimento (um processo de desenvolvimento de software) Um processo de

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

http://www.di.uminho.pt

http://www.di.uminho.pt Escola de Engenharia Departamento de Informática Desenvolvimento de Sistemas de Informação LESI 4º ano / 2º semestre (5308O7) LMCC 4º ano / 2º semestre (7008N8 Opção II) 2005/2006 José Creissac Campos

Leia mais

Curso - Padrões de Projeto Módulo 1: Introdução

Curso - Padrões de Projeto Módulo 1: Introdução Curso - Padrões de Projeto Módulo 1: Introdução Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java: Graduação

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 Segundo Exame 16 de Julho de 2010, 9:00H 11:30H (Versão A) Nome:

Leia mais

Rock In Rio - Lisboa

Rock In Rio - Lisboa Curso de Engenharia Informática Industrial Rock In Rio - Lisboa Elaborado por: Ano Lectivo: 2004/05 Tiago Costa N.º 4917 Turma: C Gustavo Graça Patrício N.º 4757 Turma: C Docente: Professora Maria Estalagem

Leia mais

Padrões. Projeto (Design) de Software

Padrões. Projeto (Design) de Software Padrões Projeto de Softwares Categorias de Padrões Processo de Tradução de modelos de análise (isentos de tecnologia, lógicos) para modelos de projeto (development-ready, físicos) Qual a Tecnologia Alvo

Leia mais

Análise OO. Análise. Antónia Lopes Desenvolvimento C. Objectos 09/10. Antónia Lopes

Análise OO. Análise. Antónia Lopes Desenvolvimento C. Objectos 09/10. Antónia Lopes Análise OO 36 Análise Análise é a investigação do problema Análise de Requisitos é o termo que designa a investigação das necessidades e condições que o sistema, e o projecto em geral, têm de satisfazer.

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

Padrões de Projeto de Software Orientado a Objetos

Padrões de Projeto de Software Orientado a Objetos Padrões de Projeto de Software Orientado a Objetos Ricardo Argenton Ramos [Baseado nos slides do professor Fabio Kon - USP] 1 Padrões de Projeto de Software OO Também conhecidos como Padrões de Desenho

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

Padrões clássicos ou padrões GoF O livro "Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de

Padrões clássicos ou padrões GoF O livro Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de Padrões de Projeto Disciplina: Engenharia de Software - 2009.1 Professora: Rossana Maria de Castro Andrade Assistente da disciplina: Ricardo Fernandes de Almeida 1 O que é um Padrão? Um padrão descreve

Leia mais

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual Engenharia de Software Sistemas Distribuídos 2º Semestre, 2007/2008 Departamento Engenharia Informática Enunciado do projecto: Loja Virtual Fevereiro de 2008 Índice Índice...2 Índice de Figuras...3 1 Introdução...4

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Concepção e Elaboração

Concepção e Elaboração 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 Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

UML jvo. 1. Disponibilizar uma linguagem de modelação visual expressiva e rigorosa;

UML jvo. 1. Disponibilizar uma linguagem de modelação visual expressiva e rigorosa; UML A Unified Modeling Language (UML) é uma linguagem, essencialmente gráfica, para modelar, especificar e documentar elementos de sistemas, não necessariamente informáticos. É um standard reconhecido

Leia mais

Separaçã. ção Multi-Dimensional de Interesses

Separaçã. ção Multi-Dimensional de Interesses OD 2002 Uma nova abordagem para modelagem de requisitos Separaçã ção Multi-Dimensional de Interesses Helder da Rocha (helder@acm.org) argonavis.com.br Objetivos 1. Discutir as limitações existentes no

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

Desenvolvimento Baseado em Componentes e o Processo UML Components

Desenvolvimento Baseado em Componentes e o Processo UML Components Desenvolvimento Baseado em Componentes e o Processo UML Components Cecília Mary Fischer Rubira Patrick Henrique da Silva Brito Instituto de Computação (IC) Universidade Estadual de Campinas (Unicamp) INF064

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

Padrões de Desenho (Design Patterns)

Padrões de Desenho (Design Patterns) Padrões de Desenho (Design Patterns) O que são padrões de desenho Porque são úteis Conhecer alguns padrões 1 Padrões (Patterns) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

Leia mais

Lisboa, 18 de Janeiro de 2004

Lisboa, 18 de Janeiro de 2004 Lisboa, 18 de Janeiro de 2004 Realizado por: o Bruno Martins Nº 17206 o Cátia Chasqueira Nº 17211 o João Almeida Nº 17230 1 Índice 1 Índice de Figuras... 3 2 Versões... 4 3 Introdução... 5 3.1 Finalidade...

Leia mais

PHC dteamcontrol Externo

PHC dteamcontrol Externo PHC dteamcontrol Externo A gestão remota de projectos e de informação A solução via Internet que permite aos seus Clientes participarem nos projectos em que estão envolvidos, interagindo na optimização

Leia mais

UML Visão Geral. Slides baseados em material disponibilizado pela Rational e adaptação da tradução de João P. Faria Univ. Do Porto.

UML Visão Geral. Slides baseados em material disponibilizado pela Rational e adaptação da tradução de João P. Faria Univ. Do Porto. UML Visão Geral Slides baseados em material disponibilizado pela Rational e adaptação da tradução de João P. Faria Univ. Do Porto. 1 Índice Introdução Diagramas O que é a UML? Diagrama de casos de uso

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Métricas para avaliação de Linguagens de

Métricas para avaliação de Linguagens de Métricas para avaliação de Linguagens de Modelação - UML José Pedro Silva Pedro Faria Ulisses Araújo Costa Resumo A utilização de diagramas de UML é importante na moelação de uma arquitectura de um sistema

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Projeto: Simul-e Documento de Arquitetura de Software

Projeto: Simul-e Documento de Arquitetura de Software Projeto: Simul-e Documento de Arquitetura de Software Versão 1.0 Página 1 de 9 Histórico da Revisão Data Versão Descrição Autor 12.09.2015 1.0 Criação do Documento Hugo Pazolline 20.10.2015 1.0 Atualização

Leia mais

Manual de Convenções. BPMN Business Process Modelling Notation. 2009 GFI Portugal

Manual de Convenções. BPMN Business Process Modelling Notation. 2009 GFI Portugal Manual de Convenções BPMN Business Process Modelling Notation 2009 GFI Portugal O que é o BPMN? O BPMN é uma notação gráfica para a definição de processos de negócio É o standard internacional para modelação

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008 Tabela de Símbolos Análise Semântica A Tabela de Símbolos Fabiano Baldo Após a árvore de derivação, a tabela de símbolos é o principal atributo herdado em um compilador. É possível, mas não necessário,

Leia mais

WebSphere_Integration_Developer_D_Jan06 Script

WebSphere_Integration_Developer_D_Jan06 Script WebSphere_Integration_Developer_D_Jan06 Script 1a Nesta demonstração, Will Dunlop, um programador de integração da JK, utiliza o IBM, [ IBM], ou WID para construir um novo serviço orientado para os processos

Leia mais

Laboratório 4 Validação do Formulário

Laboratório 4 Validação do Formulário Laboratório 4 Validação do Formulário Introdução Agora que já definimos os nossos documentos usando xhtml e já os embelezámos através da utilização das CSS, está na hora de validar a informação que o utilizador

Leia mais

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

Guia para elaboração do Modelo de Domínio Metodologia Celepar Guia para elaboração do Modelo de Domínio Metodologia Celepar Agosto 2009 Sumário de Informações do Documento Documento: guiamodelagemclassesdominio.odt Número de páginas: 20 Versão Data Mudanças Autor

Leia mais

UML (Unified Modeling Language) Linguagem de Modelagem Unificada

UML (Unified Modeling Language) Linguagem de Modelagem Unificada UML (Unified Modeling Language) Linguagem de Modelagem Unificada Introdução É a padronização das metodologias de desenvolvimento de sistemas baseados na orientação a objetos. Foi criada por três grandes

Leia mais

Padrões de Interação com o Usuário

Padrões de Interação com o Usuário Padrões de Interação com o Usuário Granularidade dos Padrões Padrões estão relacionados a 3 elementos: Contexto ocorre Problema resolve Solução Problemas e Soluções podem ser observados em diferentes níveis

Leia mais

( JUDE Community 5.1 2006/2007 ) Por Denize Terra Pimenta Outubro/2007

( JUDE Community 5.1 2006/2007 ) Por Denize Terra Pimenta Outubro/2007 Tutorial JUDE ( JUDE Community 5.1 2006/2007 ) Por Denize Terra Pimenta Outubro/2007 Ferramenta CASE UML Índice Introdução... 2 Download e Instalação... 2 Apresentação da Ferramenta... 2 Salvando o Projeto...

Leia mais

Uma introdução sobre Frameworks de Desenvolvimento

Uma introdução sobre Frameworks de Desenvolvimento Uma introdução sobre Frameworks de Desenvolvimento Waldemir Cambiucci Arquiteto de Soluções Microsoft Brasil twitter.com/wcamb ogs.msdn.com/wcamb 1 Agenda Ferramentas de produtividade Questões sobre frameworks

Leia mais

Engenharia Informática

Engenharia Informática Escola Superior de Ciência e Tecnologia Engenharia Informática Análise de Sistemas Informáticos 3º ano Exame 12 de Julho de 2006 Docentes: José Correia e João Paulo Rodrigues Duração: 90 m; Tolerância:

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Apresentação da Disciplina Edirlei Soares de Lima Objetivos da Disciplina Apresentar e discutir técnicas avançadas de Análise e Projeto de

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

Decorator Pattern. SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br. Junho de 2008. Departamento de Informática / UFMA

Decorator Pattern. SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br. Junho de 2008. Departamento de Informática / UFMA Decorator Pattern SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br Departamento de Informática / UFMA Junho de 2008 Revisando os conceitos Herança é poderosa mas não é flexível Comportamento

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

REFLEXÃO EM JAVA. INVERSÃO DE DEPENDÊNCIA FACTORY METHODS FACTORY CLASSES IoC, CONTAINERS e BEANS SPRING PARTE III

REFLEXÃO EM JAVA. INVERSÃO DE DEPENDÊNCIA FACTORY METHODS FACTORY CLASSES IoC, CONTAINERS e BEANS SPRING PARTE III REFLEXÃO EM JAVA INVERSÃO DE DEPENDÊNCIA FACTORY METHODS FACTORY CLASSES IoC, CONTAINERS e BEANS SPRING PARTE III ARQUITECTURAS DE SOFTWARE F. Mário Martins 2011 CLASS A partir de JAVA5 a classe java.lang.class

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

PHP: Programando com Orientação a Objetos

PHP: Programando com Orientação a Objetos PHP: Programando com Orientação a Objetos Pablo Dall'Oglio Adianti Solutions www.adianti.com.br Roteiro Conceitos de Orientação a Objetos; Classes, objetos, propriedades, métodos; Métodos construtores

Leia mais

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

Sumário. Uma visão mais clara da UML Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da

Leia mais

Modelando com UML Unified Modeling Language

Modelando com UML Unified Modeling Language Modelando com UML Unified Modeling Language AHMED ALI ABDALLA ESMIN 1 1 ILES ULBRA Instituto de Informática - Universidade Luterana do Brasil de Informática Cx. Postal 271 CEP 78.9860-000 Ji-Paraná (RO)

Leia mais

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br Padrões GoF Leonardo Gresta Paulino Murta leomurta@ic.uff.br Agenda Introdução Padrões de Criação Padrões de Estrutura Padrões de comportamento Leonardo Murta Padrões GoF 2 Introdução Os padrões GoF (Gamma

Leia mais

Bem vindos à técnica CRC

Bem vindos à técnica CRC Bem vindos à técnica CRC 1 Nossa Agenda Conceitos CRC do modelo de classes Serviços Apresentação do CRC Classe Solicitação Apresentação Atributos Classe Solicitação Apresentação Modelo Classes 2 O que

Leia mais

ENGENHARIA DE SOFTWARE ExtremePlanner

ENGENHARIA DE SOFTWARE ExtremePlanner ENGENHARIA DE SOFTWARE ExtremePlanner Acesso ao sistema: https://es.extremeplannerlive.com Procedimento de Login: O login e password é definido pelos caracteres iniciais do endereço de email do aluno,

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 GRUPO 10. Vítor Martins 47121. Rui Fonseca 47081. David Barbosa 47076. Ricardo Boas 47023

DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 GRUPO 10. Vítor Martins 47121. Rui Fonseca 47081. David Barbosa 47076. Ricardo Boas 47023 DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 David Barbosa 47076 Ricardo Boas 47023 Rui Fonseca 47081 Vítor Martins 47121 GRUPO 10 2009/2010 1 Índice 1. Introdução... 2 1.1 Visão Geral do Problema... 2

Leia mais

Teste de Software. Ricardo Argenton Ramos ricargentonramos@gmail.com. Engenharia de Software I 2012.2

Teste de Software. Ricardo Argenton Ramos ricargentonramos@gmail.com. Engenharia de Software I 2012.2 Teste de Software Ricardo Argenton Ramos ricargentonramos@gmail.com Engenharia de Software I 2012.2 O que diferencia teste de software OO de testes Convencionais? Técnicas e abordagens são normalmente

Leia mais