ELABORAÇÃO. GRASP General Responsibility Assignment Software Patterns. Core of OODesign. Artefactos de input para OOD
|
|
- Roberto Machado Amado
- 8 Há anos
- Visualizações:
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 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 maisARQUITECTURAS 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 maisPadrõ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 mais2 Diagrama de Caso de Uso
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa
Leia maisUNIVERSIDADE 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 maisEngenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
Leia maisRock 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 maisPadrã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 maisModelo 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 maisMúltiplos Estágios processo com três estágios Inquérito de Satisfação Fase II
O seguinte exercício contempla um processo com três estágios. Baseia-se no Inquérito de Satisfação Fase II, sendo, por isso, essencial compreender primeiro o problema antes de começar o tutorial. 1 1.
Leia maisTabela 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 maisDesenvolvimento 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 maisFeature-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 maisArquitecturas 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 maisProcesso 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 mais3.1 Definições Uma classe é a descrição de um tipo de objeto.
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:
Leia maisUML Aspectos de projetos em Diagramas de classes
UML Aspectos de projetos em Diagramas de classes Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o Diagrama de Classes com informações visando uma implementação Orientada
Leia maisDesenho 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 maisO 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 maisGereComSaber. Desenvolvimento de Sistemas de Software. Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática
Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/10 GereComSaber Ana Duarte, André Guedes, Eduardo
Leia maisAná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 maisUniversidade do Minho. Licenciatura em Engenharia Informática. Desenvolvimento de Sistemas de Software. Gere Com Saber
Universidade do Minho Gere Com Saber Grupo 3: 430 José Carvalho 4377 Pedro Ribeiro 4394 Tiago Airosa 49333 Bernardino Fernandes 4936 Luís Carvalho Índice ÍNDICE ÍNDICE DE FIGURAS 5 INTRODUÇÃO 7. MODELO
Leia maisPROGRAMAÇÃ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 maisModelagem 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 maisEntendendo como funciona o NAT
Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços
Leia maisDiagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.
1 Diagrama de Classes Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes. Um dos objetivos do diagrama de classes é definir a base para
Leia maisAnálise e Projeto Orientado a Objetos. Modelagem de Domínio
+ Análise e Projeto Orientado a Objetos Modelagem de Domínio Introdução 2 n A modelagem do domínio está relacionada à descoberta das informações que são gerenciadas pelo sistema. O resultado dessa investigação
Leia maisEngenharia 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 maisEXERCÍCIOS SOBRE ORIENTAÇÃO A OBJETOS
Campus Cachoeiro de Itapemirim Curso Técnico em Informática Disciplina: Análise e Projeto de Sistemas Professor: Rafael Vargas Mesquita Este exercício deve ser manuscrito e entregue na próxima aula; Valor
Leia maisAspectos técnicos do desenvolvimento baseado em componentes
Aspectos técnicos do desenvolvimento baseado em componentes Um novo processo de desenvolvimento O uso de componentes traz mudanças no processo de desenvolvimento Além de desenvolver um produto, queremos
Leia maisTECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO
TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS BÁSICOS 1 Necessidade das base de dados Permite guardar dados dos mais variados tipos; Permite
Leia maisCertificação da Qualidade dos Serviços Sociais. Procedimentos
Certificação da Qualidade dos Serviços Sociais EQUASS Assurance Procedimentos 2008 - European Quality in Social Services (EQUASS) Reservados todos os direitos. É proibida a reprodução total ou parcial
Leia maisTRABALHO 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 maisConteú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 maisBPMN Business Process Modeling Notation
BPMN Business Process Modeling Notation Business Process Modeling Notation Página 1 Objetivo O objetivo deste curso é apresentar os elementos da notação de modelagem de processos de negócio BPMN 1.1 (Business
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia maisFelipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet)
UML Felipe Denis M. de Oliveira Fonte: Alice e Carlos Rodrigo (Internet) 1 Programação O que é UML? Por quê UML? Benefícios Diagramas Use Case Class State Interaction Sequence Collaboration Activity Physical
Leia maisProf. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.
Casos de Uso de Alto Nível Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Contexto Na fase de concepção
Leia maisProgramaçã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 maisGereComSaber. 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 maisPrograma de Parcerias e Submissão de Propostas 2014/15
DEPARTAMENTO DE INFORMÁTICA Programa de Parcerias e Submissão de Propostas 2014/15 O Departamento de Informática (DI) da Faculdade de Ciências da Universidade de Lisboa (FCUL) procura criar e estreitar
Leia maisAnálise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)
Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem
Leia maisResolução da lista de exercícios de casos de uso
Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se
Leia maisAnálise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com
Análise e Projeto de Sistemas de Informação Andrêza Leite andreza.lba@gmail.com Roteiro Sistemas de Informação Ciclo de Desenvolvimento de SI Projeto Análise Estruturada Análise Orientada a Objetos Como
Leia mais4.1. UML Diagramas de casos de uso
Engenharia de Software 4.1. UML Diagramas de casos de uso Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Utilizados para ajudar na análise de requisitos Através da forma como o utilizador usa o sistema
Leia maisDadas a base e a altura de um triangulo, determinar sua área.
Disciplina Lógica de Programação Visual Ana Rita Dutra dos Santos Especialista em Novas Tecnologias aplicadas a Educação Mestranda em Informática aplicada a Educação ana.santos@qi.edu.br Conceitos Preliminares
Leia maisO Manual do ssc. Peter H. Grasch
Peter H. Grasch 2 Conteúdo 1 Introdução 6 2 Usar o ssc 7 2.1 Gerir os utilizadores.................................... 7 2.1.1 Adicionar um utilizador.............................. 8 2.1.1.1 Associar-se
Leia maisEspecificação do 3º Trabalho
Especificação do 3º Trabalho I. Introdução O objetivo deste trabalho é abordar a prática da programação orientada a objetos usando a linguagem Java envolvendo os conceitos de classe, objeto, associação,
Leia maisModelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.
UML Diagramas Um diagrama é a apresentação gráfica de um conjunto de elementos, onde os vértices são ITENS e os arcos RELACIONAMENTOS UML 2.0 possui os seguintes diagramas: Diagrama de Classes (Class Diagram)
Leia maisOrientação a Objetos
1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou
Leia maisPROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às
Leia maisARQUITECTURAS 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 maisEngenharia de Software I
Engenharia de Software I Curso de Desenvolvimento de Software Prof. Alessandro J de Souza ajdsouza@cefetrn.br 1 Rational Unified Process RUP Fase Elaboração 2 VISÃO GERAL Fase Elaboração. Visão Geral 3
Leia maisManual técnico. v2.2 2015/10
Manual técnico v2.2 2015/10 Índice 1. INTRODUÇÃO... 3 2. DESCRIÇÃO... 3 3. INTEGRAÇÃO DO SISTEMA... 4 3.1 DESCRIÇÃO... 4 3.2 INTEGRAÇÃO... 5 3.2.1. Geração de referências... 5 getreferencemb...5 getreferencemb2...7
Leia maisAgentes Inteligentes segundo o Chimera
Agentes Inteligentes segundo o Chimera C Heuristic I M E R A No ambiente de desenvolvimento de Agentes Inteligentes Chimera, uma extensão do LPA Win-Prolog, um agente é funcionalmente composto por: Código,
Leia maisPADRÕ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 maisDiagrama 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 maisWebSphere_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 maisConcepçã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 maisDecorator 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 maisEngenharia de Software Sistemas Distribuídos
Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 FEARSe Requisitos para a 1 a entrega 18 de Março de 2010 1 Introdução O projecto conjunto das disciplinas de Engenharia de Software
Leia maisPHC Serviços CS. A gestão de processos de prestação de serviços
PHC Serviços CS A gestão de processos de prestação de serviços A solução que permite controlar diferentes áreas de uma empresa: reclamações e respectivo tratamento; controlo de processos e respectivos
Leia maisDESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES
DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.
Leia maisPrototype, um Design Patterns de Criação
Prototype, um Design Patterns de Criação José Anízio Pantoja Maia Este artigo tem como finalidade compreender o funcionamento do padrão de projeto prototype, serão abordados os participantes que compõe
Leia maisDe 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 maisAnálise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN
Análise e Projeto Orientados a Objetos Aula IV Requisitos Prof.: Bruno E. G. Gomes IFRN 1 Introdução Etapa relacionada a descoberta e descrição das funcionalidades do sistema Parte significativa da fase
Leia mais2 Engenharia de Software
20 2 Engenharia de Software 2.1 Design de Sistemas Orientados a Objetos Os Sistemas Orientados a Objetos não são mais novidade hoje em dia já estando há muitos anos no mercado. A orientação a objetos permite
Leia maisUML 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 maisPHC dteamcontrol Externo
PHC dteamcontrol Externo A gestão remota de projetos e de informação A solução via Internet que permite aos seus Clientes participarem nos projetos em que estão envolvidos, interagindo na otimização dos
Leia maisProgramação Orientada a Objetos Herança Técnico em Informática. Prof. Marcos André Pisching, M.Sc.
Herança Técnico em Informática, M.Sc. Herança 2 Herança Reutilização de código Exemplo Banco: Um banco oferece diversos serviços que podem ser contratados individualmente pelos clientes. Quando um serviço
Leia maisDesenvolvimento 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 maisUnisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER
Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem
Leia maisPLANOS DE CONTINGÊNCIAS
PLANOS DE CONTINGÊNCIAS ARAÚJO GOMES Capitão SC PMSC ARAÚJO GOMES defesacivilgomes@yahoo.com.br PLANO DE CONTINGÊNCIA O planejamento para emergências é complexo por suas características intrínsecas. Como
Leia maisUNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas
UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar
Leia maisReferências internas são os artefatos usados para ajudar na elaboração do PT tais como:
Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código
Leia maisO 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 maisRequisitos 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 maisWilson Moraes Góes. Novatec
Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,
Leia maisUnified 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 mais3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio
32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio
Leia maisGestão dos Níveis de Serviço
A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento
Leia mais)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR
6LPXODomR GH6LVWHPDV )HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR #5,6. Simulador voltado para análise de risco financeiro 3RQWRV IRUWHV Fácil de usar. Funciona integrado a ferramentas já bastante conhecidas,
Leia mais4.4. UML Diagramas de interacção
Engenharia de Software 4.4. UML Diagramas de interacção Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de interacção mostra um padrão de interacção entre vários objectos, com objectos e
Leia maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
Leia maisPrograma 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 maisDesenvolvimento de Sistema de Software
Desenvolvimento de Sistema de Software Grupo 5 Abel Matos 51776 João Amorim 51771 João Guedes 51755 Luís Oliveira 51801 Pedro Reis 51829 Introdução Neste relatório, realizado no âmbito da primeira fase
Leia maisUFG - Instituto de Informática
UFG - Instituto de Informática Curso: Sistemas de Informação Arquitetura de Software Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 3 Introdução à Arquitetura de Software (continuação)
Leia maisOrganização. Trabalho realizado por: André Palma nº 31093. Daniel Jesus nº 28571. Fábio Bota nº 25874. Stephane Fernandes nº 28591
Organização Trabalho realizado por: André Palma nº 31093 Daniel Jesus nº 28571 Fábio Bota nº 25874 Stephane Fernandes nº 28591 Índice Introdução...3 Conceitos.6 Princípios de uma organização. 7 Posição
Leia maisUma 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 maisProgramação Orientada a Objeto
Programação Orientada a Objeto Classes, Atributos, Métodos e Objetos Programação de Computadores II Professor: Edwar Saliba Júnior 1) Java é uma linguagem orientada a objetos. Para que possamos fazer uso
Leia maisTema 1: Modelo Estático
Tema 1: Modelo Estático (fonte: http://www.macoratti.net/net_uml1.htm) A Programação Orientada a Objetos (POO) baseia-se na descoberta dos objetos que compõem um determinado escopo e nas trocas de mensagens
Leia maisNovo Formato de Logins Manual de Consulta
Gestão Integrada de Acessos Novo Formato de Logins Manual de Consulta Gestão Integrada de Acessos Histórico de Alterações Versão Descrição Autor Data 1.0 Versão inicial DSI/PPQ 2014-07-11 Controlo do documento
Leia mais15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função
Análise por pontos de função Análise por Pontos de Função Referência: Manual de práticas de contagem IFPUG Versão 4.2.1 Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão
Leia maisDESENVOLVIMENTO 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 maisCapítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1
Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de
Leia maisEngenharia de software para desenvolvimento com LabVIEW: Validação
Engenharia de software para desenvolvimento com LabVIEW: Orientação a Objetos, Statechart e Validação André Pereira Engenheiro de Vendas (Grande São Paulo) Alexsander Loula Coordenador Suporte Técnico
Leia mais