Reuso de C´ odigo

Diego Passos

Universidade Federal Fluminense

T´ ecnicas de Projeto e Implementac ¸˜ ao de Sistemas I

Introduc¸˜ ao

Nesta disciplina, citamos repetidamente os benef´ıcios do reuso de

software.

I Reduc¸˜ao do tempo de desenvolvimento.

I Reduc¸˜ao do tempo de testes.

I Reduc¸˜ao dos custos.

I Reduc¸˜ao dos riscos.

I Reduc¸˜ao do n´umero debugs.

I . . .

Via de regra, quanto maior nossa capacidade de reuso, melhor.

Introduc¸˜ ao (II)

Durante a segunda parte do curso, focamos nos padr˜ oes de projeto.

I Soluc¸˜oesreutiliz´aveispara problemas desoftware.

I Padr˜oes de projeto s˜ao, portanto, uma forma de reutilizac¸˜ao na engenharia desoftware.

No entanto, a reutilizac ¸˜ ao atrav´ es de padr˜ oes de projeto ´ e feita de forma indireta.

I Padr˜oes de projeto est˜ao em um n´ıvel alto de abstrac¸˜ao.

I Segundo Sommerville, os padr˜oes de projeto s˜ao uma abordagem dereuso conceitual.

I Prop˜oemtemplates de soluc¸˜oes de projeto.

F Desenvolvedor precisa concretizar otemplate.

Introduc¸˜ ao (III)

O reuso, na engenharia de

software, pode ser feito em n´ıveis mais baixos.

I Mais diretamente relacionados ao c´odigo.

Exemplos de abordagens de reuso:

I Bibliotecas.

I Desenvolvimento baseado em componentes.

I Wrapping de sistemas legados.

I Sistemas orientados a servic¸os.

I Integrac¸˜ao de sistemas COTS.

I Frameworks de Aplicac¸˜ao.

I Linhas de produto.

I . . .

Reuso de C´ odigo: Bibliotecas

Abordagem bastante comum para reuso de c´ odigo.

Funcionalidades comuns a diversos sistemas de

software

s˜ ao encapsulados em uma unidade chamada biblioteca.

Uma mesma biblioteca pode ser usada por m´ ultiplos

softwares.

Uma mesma aplicac ¸˜ ao pode usar m´ ultiplas bibliotecas.

H´ a v´ arias maneiras de uma aplicac¸˜ ao incluir c´ odigo (funcionalidades) de uma biblioteca:

I Link dinˆamico.

I Link est´atico.

Reuso de C´ odigo: Desenvolvimento Baseado em Componentes

Componentes s˜ ao unidades de

software

independentes e com funcionalidade bem definida.

Podem ser adicionados ` a aplicac ¸˜ oes para prover a funcionalidade desejada.

No desenvolvimento baseado em componentes, uma aplicac ¸˜ ao ´ e basicamente uma composic ¸˜ ao de v´ arios componentes.

I O conjunto destes componentes fornece as funcionalidades da aplicac¸˜ao.

O conceito de componentes ´ e comumente encontrado no desenvolvimento de interfaces com o usu´ ario.

I Exemplo: tecnologia JSF.

Reuso de C´ odigo: Wrapping de Sistemas Legados

Outra forma de reuso de c´ odigo ´ e o

Wrapping

de Sistemas Legados.

Suponha, por exemplo, que um banco possui um sistema antigo para gerenciamento das transac¸˜ oes de seus clientes.

I Sistema funciona corretamente e ´e est´avel.

I Mas ´e muito antigo e n˜ao ´e compat´ıvel com tecnologias novas que o banco deseja implantar.

Ao inv´ es de reescrevermos todo o sistema apenas para dar suporte ` as novas tecnologias, fazemos um

wrapping

:

I Adicionamos ao sistema antigo novas interfaces.

I Estas interfaces permitem a integrac¸˜ao do sistema legado com as novas tecnologias.

Reuso de C´ odigo: Sistemas Orientados a Servic¸os

Nesta abordagem, constru´ımos um novo sistema com base em sistemas j´ a existentes.

Neste cen´ ario, os sistemas j´ a existentes fornecem servic ¸os.

I Acessados, por exemplo, via rede.

Ao inv´ es do novo sistema reimplementar estes servic ¸os, ele faz pedidos/consultas aos sistemas j´ a existentes.

I Em outras palavras, novo sistema interliga os sistemas j´a existentes.

I Com isso, conseguimos ofertar a funcionalidade desejada.

Exemplo:

I Sistema de monitoramento de trˆansito.

I Utiliza sistema da prefeitura que fornece informac¸˜oes sobre o trˆansito.

I Utiliza sistema de geo-referˆencia (GoogleMaps, BingMaps, ...) para exibir informac¸˜oes em um mapa.

Reuso de C´ odigo: Integrac¸˜ ao de Sistemas COTS

COTS:

Common Off-The-Shelf.

I Sistemas completos, prontamente dispon´ıveis.

I Aplicac¸˜oes prontas.

Podemos construir sistemas de

software

complexos integrando sistemas COTS.

Exemplo: Sistema de

e-commerce.

I Interface com o usu´ario ´e feita atrav´es deweb browser.

I No servidor, sistema integra outras aplicac¸˜oes como:

F Servidor de e-mail (SMTP).

F Aplicac¸˜ao pronta para manipulac¸˜ao de estoque.

F ...

Reuso de C´ odigo: Frameworks de Aplicac¸˜ ao

Frameworks

s˜ ao um conjunto de classes concretas e abstratas e suas interfaces.

Um

framework

fornece um projeto parcial de um sistema.

I Para alguns autores, oframework´e um sub-sistema.

Desenvolvedor pode criar um sistema completo atrav´ es de:

I Instanciac¸˜ao das classes abstratas.

I Extens˜ao das classes concretas.

I Adic¸˜ao de componentes.

Frameworks, em geral, fornecem as funcionalidades b´

asicas para um determinado tipo de sistema.

I As personalizac¸˜oes feitas pelo desenvolvedor determinam as especificidades da aplicac¸˜ao final.

Reuso de C´ odigo: Frameworks de Aplicac¸˜ ao (II)

Note que existe uma diferenc¸a fundamental entre os

frameworks

e as bibliotecas:

I Bibliotecas tˆem funcionalidades chamadas pela c´odigo do desenvolvedor.

F i.e., fluxo de execuc¸˜ao ´e ditado pelo c´odigo do desenvolvedor.

I Frameworks chamamc´odigo do desenvolvedor.

F Fluxo de execuc¸˜ao ´e ditado peloframework.

F Papeis s˜ao invertidos.

F Princ´ıpio de Hollywood.

Outra diferenc ¸a ´ e a existˆ encia de um

comportamento padr˜ao.

I Frameworks geralmente fornecem implementac¸˜oes por omiss˜ao quepodemser alteradas pelo

Reuso de C´ odigo: Frameworks de Aplicac¸˜ ao (III)

Frameworks

s˜ ao em geral grandes “pedac ¸os” de

software.

I O c´odigo escrito pelo desenvolvedor, por outro lado, ´e pequeno.

A ideia ´ e justamente limitar o esforc ¸o do desenvolvedor para criar um tipo de sistema.

I Framework provˆe a maior parte do c´odigo.

I Indicahot spots nos quais o desenvolvedor pode colocar suas personalizac¸˜oes.

De forma bastante abstrata, o

framework

´ e como um o sistema

quase

completo.

I O trabalho do desenvolvedor ´e preencher as lacunas.

Exemplo de Framework : JSF

JSF:

Java Server Faces.

Framework

para desenvolvimento de aplicac¸˜ oes web em Java.

Implementa o padr˜ ao

Model-View-Controller.

I Model eView s˜ao fornecidos pelo desenvolvedor.

I Controller ´e totalmente implementado pelo JSF.

Exemplo de Framework : JSF (II)

Faces Servlet

Views View 1

View 2 ...

View n

Beans Gerenciadas Bean 1 Bean 2 ...

Bean m Renderiza

Lê/Armazena Dados Executa Métodos

Biblioteca de Componentes Componente 1

Componente 2 ...

Componente k Responsabilidade do

Desenvolvedor

O

Faces Servlet

´ e provido pelo

framework.

Respons´ avel pelo trabalho pesado.

I Receber requisic¸˜oes dos clientes.

I Decidir qualview exibir.

I Entender dados fornecidos pelo usu´ario (e armazen´a-los nas beans adequadas).

I Identificar eventos e chamar m´etodos de neg´ocio adequados.

I . . .

Framework

provˆ e ainda biblioteca de

componentes visuais para as

views.

Exemplo de Framework : JSF (III)

Faces Servlet

Views View 1

View 2 ...

View n

Beans Gerenciadas Bean 1 Renderiza

Biblioteca de Componentes Componente 1

Componente 2 ...

Componente k Responsabilidade do

Desenvolvedor

Tarefa do desenvolvedor fica restrita a:

I Desenvolvertemplates para a interface gr´afica.

F JSP.

I Desenvolver beans.

F Classes Java que implementam l´ogica de neg´ocio

Os

templates

associam componentes de

interface a propriedades ou m´ etodos das

beans.

Exemplo de Framework : JSF (IV)

E poss´ıvel escrever aplicac¸˜ ´ oes

web

“do zero” em linguagens como PHP, JSP, ASP.

I Neste caso, cabe ao desenvolvedor o ˆonus de fazer a conex˜ao entre a interface, os eventos, e a l´ogica de neg´ocio.

I Tamb´em precisa lidar com conceitos como gerenciamento de sess˜oes, cookies, . . .

JSF tira esta tarefa do desenvolvedor, que agora s´ o se preocupa com

templates

da interface

e com os m´ etodos/classes de l´ ogica de neg´ ocio.

Exemplo de Framework : Django

Framework

para aplicac ¸˜ oes web em Python.

Em v´ arios aspectos, similar ao JSF.

I Aplicac¸˜oes web.

I Implementa o MVC.

I Utiliza conceito de componentes.

Mas v´ arias diferenc¸as:

I Linguagem.

I Foco em aplicac¸˜oes com uso pesado de Banco de Dados.

Exemplo de Framework : Django (II)

O Django possui um mapeador objeto relacional.

I Desenvolvedor cria classes em Python para representar informac¸˜oes.

F Modelos de dados.

I Mapeador cria (e gerencia) representac¸˜oes destas classes em uma base relacional.

Isto permite a f´ acil manipulac¸˜ ao pela aplicac ¸˜ ao das informac ¸˜ oes da base.

I S˜ao tratadas como objetos comuns.

Exemplo de Framework : Django (III)

A interface com o usu´ ario ´ e desenvolvida atrav´ es da criac ¸˜ ao de

templates web.

Estes

templates

descrevem a interface de forma geral.

Um

template

pode ser usado em conjunto com uma

view

para servir conte´ udo dinˆ amico.

O Django tem ainda um mecanismo baseado em express˜ oes regulares para mapear URLs

acessadas pelo usu´ ario para

views

espec´ıficas.

Linhas de Produto: Motivac¸˜ ao

A maneira como produtos s˜ ao produzidos na industria mudou bastante durante a hist´ oria.

I Antigamente, o m´etodo mais comum era a produc¸˜ao voltada para consumidores individuais.

I Exemplo (ainda comum hoje): alfaiate.

I Poucas pessoas tinham acesso a determinados produtos.

I Produc¸˜ao individual era vi´avel.

Eventualmente, criou-se o conceito de

linha de produc¸˜ao.

I Produc¸˜ao de bensem massa.

I Acompanhou o aumento no n´umero de pessoas capazes de comprar certos produtos.

I Reduziu os custos.

I Mas tamb´em trouxe uma desvantagem clara: a dificuldade de personalizar os produtos.

Linhas de Produto: Motivac¸˜ ao (II)

Os conceitos de produtos individualizados e em massa ocorrem tamb´ em no desenvolvimento de

software.

H´ a

softwares

individuais.

I Desenvolvidos do zero, sob medida.

I Equipe de desenvolvimento realiza o levantamento de requisitos com o cliente.

I Faz um projeto voltado especificamente para aquele ambiente.

I Software tem todas (ou quase todas) as especificidades desejadas pelo cliente.

H´ a tamb´ em os

softwares

padronizados:

I Soluc¸˜oes gen´ericas para um dado problema comum h´a diversos clientes.

Exemplo comum: softwarede ponto de venda.

Linhas de Produto: Motivac¸˜ ao (III)

Os

softwares

padronizados s˜ ao ´ otimos do ponto de vista do reuso.

I A mesma soluc¸˜ao ´e fornecida a m´ultiplos clientes.

I Bugs encontrados por um cliente, se aplicam a todos os outros.

I Atualizac¸˜oes, correc¸˜oes e melhorias em geral tamb´em.

Por outro lado, o

software

individualizado em geral agrada mais ao cliente.

I Tem todos os recursos que ele precisa.

I E apenas os necess´arios.

I Tende a ser mais simples de usar.

O ideal seria uma soluc ¸˜ ao que combinasse os dois conceitos.

I Personaliz´avel.

I Mas com alto grau de reuso desoftware.

E exatamente neste ponto que entra a ideia de Linha de Produto. ´

Linhas de Produto: Personalizac¸˜ ao em Massa

Considere o exemplo de uma montadora de carros.

Inicialmente, ela fazia produtos individualizados.

I Carros eram produzidos sob demanda.

I O que permitia ao cliente requisitar personalizac¸˜oes.

Ap´ os algum tempo, ela migrou para o conceito de linha de produc ¸˜ ao.

I Agora carros s˜ao produzidos em massa.

I Todos os carros que saem da linha s˜ao idˆenticos.

I Reduz custos, tempo de produc¸˜ao, probabilidade de defeitos de fabricac¸˜ao.

Mas os clientes n˜ ao est˜ ao satisfeitos.

Linhas de Produto: Personalizac¸˜ ao em Massa (II)

Diretoria da f´ abrica tem ent˜ ao uma ideia:

I Ao inv´es de ter uma ´unica linha de produc¸˜ao, teremos algumas.

I Cada linha de produc¸˜ao produzir´a um modelo de carro diferente.

I Estes modelos atender˜ao a necessidades/perfis diferentes dos clientes.

Entre em cena um novo conceito:

Personalizac¸˜ ao em Massa

Produc ¸˜ ao em larga escala de produtos especializados para as necessidades individuais dos

clientes.

Linhas de Produto: Plataformas

Do ponto de vista dos clientes, a Personalizac¸˜ ao em Massa ´ e ´ otima:

I Traz de volta o poder de adquirir produtos adequados a sua necessidade.

Para a empresa que os produz, nem tanto:

I Ter v´arios produtos personalizados demanda mais investimento.

I Prec¸o de produc¸˜ao aumenta.

I O que potencialmente afastar´a clientes.

Para viabilizar o conceito, ´ e necess´ ario facilitar o processo de produc ¸˜ ao por parte da

ind´ ustria.

Linhas de Produto: Plataformas (II)

A ind´ ustria automobil´ıstica encontrou como soluc¸˜ ao a introduc ¸˜ ao de

plataformas

comuns aos seus v´ arios modelos.

I No caso de um carro, uma plataforma tipicamente inclui elementos como o chassi, e o sistema de suspens˜ao.

I Em resumo, a “base” do autom´ovel.

I A esta base, o fabricante pode adicionar tipos vari´aveis para as demais pec¸as, resultando em modelos diferentes.

De forma mais gen´ erica:

Plataforma

Qualquer base de tecnologias sobre a qual outras tecnologias ou processos podem ser constru´ıdos.

Em geral, a plataforma ´ e a parte mais custosa do projeto e da fabricac ¸˜ ao do produto.

Ter uma plataforma comum a v´ arios modelos permite reduzir os custos de desenvolvimento e produc ¸˜ ao.

I Ao mesmo tempo, permite uma grande diversidade de produtos.

Linhas de Produto: Plataformas (III)

O conceito de plataformas foi muito bem sucedido em diversas ind´ ustrias.

Exemplo real: Kodak no in´ıcio da d´ ecada de 90.

I Ao final da d´ecada de 80, a Kodak comec¸ou a perder mercado.

I A empresa, ent˜ao, investiu no desenvolvimento de uma plataforma comum que pudesse ser a base de m´ultiplos produtos.

I Construiu um modelo padr˜ao e outros trˆes modelos especializados.

F Todos usando a mesma plataforma.

F Compartilhando grande parte dos componentes.

I Diversidade atraiu consumidores.

Linhas de Produto: Engenharia de Software

No contexto da engenharia de

software, a combinac

¸˜ ao dos conceitos de plataforma de personalizac ¸˜ ao em massa deu origem a um paradigma de desenvolvimento.

I Software Product Line Engineering.

I Traduc¸˜ao livre: Engenharia de Linhas de Produtos de Software.

Neste paradigma, desenvolve-se uma plataforma de software, comum a m´ ultiplos produtos.

Esta plataforma deve ser projetada de forma a possibilitar a f´ acil criac ¸˜ ao de produtos personalizados.

A plataforma tamb´ em deve representar uma porc ¸˜ ao significativa do c´ odigo total dos produtos.

I Se este ´e o caso, h´a um alto grau de reutilizac¸˜ao desoftware.

Linhas de Produto: Criac¸˜ ao de uma Plataforma

A criac ¸˜ ao da plataforma ´ e de fundamental importˆ ancia no uso do paradigma de linhas de produtos.

Se queremos desenvolver v´ arios produtos sobre uma plataforma comum, est´ a precisa atender a todos eles.

Ela deve conter todas as partes comuns aos produtos.

Ela deve tamb´ em especificar o que deve ser espec´ıfico dos modelos a serem desenvolvidos sobre ela.

Uma boa plataforma tamb´ em deve ser projetada assumindo-se que novos produtos (ainda

n˜ ao idealizados) poder˜ ao ser criados.

Linhas de Produto: Criac¸˜ ao de uma Plataforma

Dada a importˆ ancia e a complexidade da plataforma, esta ´ e comumente constru´ıda como um projeto individual.

I Uma vez pronta, pode ser usada em outros projetos de aplicac¸˜oes espec´ıficas.

I Os outros projetos, portanto, usam os artefatos constru´ıdos no projeto da plataforma.

Nesta abordagem, o projeto da plataforma se foca no que ´ e comum.

I Aplicac¸˜oes desenvolvidas sobre a plataforma se focam no que ´e diferente.

Linhas de Produto: Variabilidade

Flexibilidade ´ e o conceito chave no desenvolvimento de uma plataforma.

I Ela deve ser flex´ıvel o suficiente para se adaptar aos requisitos detodas as aplicac¸˜oes a serem constru´ıdas sobre ela.

I Quanto maior a flexibilidade, maior o n´umero de aplicac¸˜oes distintas poss´ıveis.

Um ponto fundamental ´ e que este grau de flexibilidade esteja bem documentado.

I O que pode ser personalizado?

I At´e que ponto?

I A quais regras as personalizac¸˜oes tˆem que obedecer?

No contexto de linhas de produtos de

software

esta flexibilidade recebe o nome de

Linhas de Produto: Padronizac¸˜ ao

O emprego do conceito de linhas de produtos tipicamente leva ao estabelecimento de padr˜ oes mais r´ıgidos dentro de uma empresa.

Em empresas que fabricam produtos independentes, as equipes/setores de desenvolvimento de cada produto tˆ em tamb´ em um certo grau de independˆ encia.

I H´a uma liberdade maior para decis˜oes de projeto.

I Pode-se, por exemplo, trabalhar com tecnologias diferentes para os v´arios projetos.

I Tamb´em n˜ao h´a muita dependˆencia de cronogramas e fluxos de trabalho.

No caso da adoc¸˜ ao de uma plataforma comum para m´ ultiplos produtos, a situac ¸˜ ao muda.

I Produtos finais dependem da plataforma.

I Plataforma geralmente dita certas decis˜oes, como tecnologias usadas.

I Processos tendem a ser padronizados.

Linhas de Produto: Reduc¸˜ ao de Custos

Uma vantagem potencial do desenvolvimento de

software

utilizando linhas de produtos ´ e a reduc ¸˜ ao de custos.

I A reutilizac¸˜ao da plataforma faz com que os componentes comuns dos produtos n˜ao precisem mais ser desenvolvidos.

I Menor custo em termos de m˜ao de obra para desenvolvimento e testes.

Note, no entanto, que ´ e necess´ ario um

investimento inicial.

I A plataforma, em si, precisa ser desenvolvida.

I H´a um custo associado.

I Lembre-se que a plataforma ´e um projeto complexo.

No entanto, uma vez que a plataforma esteja pronta, a produc ¸˜ ao dos produtos tende a ser

Linhas de Produtos: Reduc¸˜ ao de Custos (II)

A resposta

normalmente

´ e sim.

Mas, na pr´ atica, isto depende de alguns fatores.

Por exemplo, investir em criar uma plataforma provavelmente n˜ ao valer´ a a pena se criarmos apenas um produto sobre ela.

I Seria mais f´acil desenvolvermos do zero o produto inicialmente.

I Logo, quanto mais produtos sobre a plataforma, maior a probabilidade de reduc¸˜ao de custos.

Accumulated Costs

Number of Different Systems Single Systems

System Family

Break-Even Point Up-Front

Investment

Lower Costs per System

approx. 3 Systems (Software Engineering)

(Fonte:Software Product Line Engineering: Foundations, Principles and Techniques)

Linhas de Produtos: Reduc¸˜ ao de Custos (III)

Se construirmos um n´ umero suficientemente grande de produtos sobre uma dada plataforma, chegaremos a um ponto onde o custo

acumulado

´ e igual.

I Break-even point.

Deste ponto em diante, o paradigma de linha de produto resulta, de fato, em reduc ¸˜ ao de custos.

A localizac ¸˜ ao exata deste ponto depende de v´ arios fatores:

I Tipo de produto, organizac¸˜ao da empresa, . . .

Accumulated Costs

Number of Different Systems Single Systems

System Family

Break-Even Point Up-Front

Investment

Lower Costs per System

approx. 3 Systems (Software Engineering)

Linhas de Produtos: Melhora da Qualidade

Outra consequˆ encia comum do paradigma baseado em linhas de produtos ´ e o aumento da qualidade do

software.

Como v´ arios produtos compartilham uma mesma plataforma:

I O c´odigo base ´e testado mais frequentemente.

I Por grupos potencialmente diferentes de usu´arios.

I Em condic¸˜oes e contextos potencialmente distintos.

Resultado: maior probabilidade de encontrar bugs.

A correc ¸˜ ao tamb´ em ´ e mais facilmente propagada para todos os produtos.

Linhas de Produtos: Time To Market

Uma m´ etrica importante em desenvolvimento de software ´ e o

time to market.

I Tempo desde o in´ıcio de um projeto at´e que o softwareseja efetivamente colocado em ambiente de produc¸˜ao.

Obviamente, gostar´ıamos de ter o menor

time to market

poss´ıvel.

I Respeitando os requisitos e a qualidade do produto.

O emprego de uma linha de produto pode auxiliar na reduc ¸˜ ao deste tempo.

I Racioc´ınio semelhante ao do custo de desenvolvimento.

Linhas de Produtos: Time To Market

Analogamente ao custo, n˜ ao h´ a ganho em termos de

time to market

se produzirmos apenas um produto.

I O tempo inicial de desenvolvimento da plataforma piora o tempo total at´e entrega do primeiro produto.

A medida que mais produtos s˜ ao criados, o tempo inicial de criac¸˜ ao da plataforma ´ e

amortizado.

I O tempo m´edio, por produto, ´e gradativamente reduzido.

Time to Market

Number of Different Systems Single Systems System Family Time for Building

Common Artefacts

Shorter Development Cycles due to Reuse

(Fonte:Software Product Line Engineering: Foundations, Principles and Techniques)

Linhas de Produtos: Outros Potenciais Benef´ıcios

Reduc ¸˜ ao do esforc ¸o de manutenc ¸˜ ao.

I Em geral, ´e mais f´acil fazer a manutenc¸˜ao densistemas com uma plataforma comum quen sistemas independentes.

I Alterac¸˜oes no c´odigo da plataforma s˜ao automaticamente propagados para os produtos.

I V´arios tipos de testes precisam ser feitos apenas uma vez.

F Embora alterac¸˜oes na plataforma exijam ainda testes nos produtos finais.

Evoluc ¸˜ ao do sistema simplificada.

I Em certos casos, as linhas de produto permitem uma simplificac¸˜ao no processo de evoluc¸˜ao.

I Certas funcionalidades podem ser adicionadas, de forma independente, diretamente `a

Linhas de Produtos: Outros Potenciais Benef´ıcios (II)

Reduc ¸˜ ao de complexidade;

I Uma abordagem alternativa para prover personalizac¸˜ao de produtos desoftware´e a inclus˜ao de recursos variados em um ´unico produto.

I Software oferece v´arios recursos e opc¸˜oes de personalizac¸˜ao em tempo de execuc¸˜ao.

I Permite ao usu´ario mold´a-lo `as suas preferˆencias.

I Por outro lado, aumenta a complexidade.

I Ao utilizar o paradigma de linha de produto, podemos criar produtos separados com as personalizac¸˜oes.

I Cada produto, individualmente, ter´a c´odigo muito mais simples.

Melhores estimativas de custo.

I Com uma plataforma pronta, o desenvolvimento dos produtos ´e simplificado.

I Como consequˆencia, ´e mais f´acil prever custos (e prazos).

Linhas de Produtos: Benef´ıcios para os Clientes

O principal benef´ıcio para os clientes est´ a na possibilidade de adquirir produtos personalizados.

Mas todos os benef´ıcios citados anteriormente, podem afetar positivamente o cliente:

I A reduc¸˜ao de custos e esforc¸o de manutenc¸˜ao pode se traduzir em prec¸o mais baixo.

I A melhoria nas estimativas de custo e prazos se traduzem em mais previsibilidade na contratac¸˜ao.

I A simplificac¸˜ao da evoluc¸˜ao do sistema se traduz em mais funcionalidades entregues ao cliente.

I A reduc¸˜ao dotime to market se traduz no cliente obter o produto mais rapidamente.

I A melhoria na qualidade do c´odigo se traduz em um sistema mais est´avel e confi´avel para o cliente.

No documento Técnicas de Projeto e Implementação de Sistemas I (páginas 85-131)