TÓPICO 2 – DESENVOLVIMENTO DE SOFTWARE
66
TÓPICO 1
DESIGN DE SOFTWARE
UNIDADE 2
1 INTRODUÇÃO
Ao decidir pela construção de algo, seja tangível ou intangível, há uma série de etapas que são comuns. Ao optar por construir uma casa você decide qual será o processo construtivo a ser adotado. Este processo poderá ser linear, incremental ou iterativo.
Você também definirá quais são os requisitos da sua construção. No caso do exemplo da casa, é a definição da quantidade de cômodos, banheiros, tipo de acabamento, tamanho da garagem, estilo do telhado etc.
A etapa seguinte é transformar estes requisitos em uma planta para que uma equipe de obras civis possa realizar a construção. Esta planta incluirá uma série de aspectos que deverão ser seguidos para que os requisitos funcionais e não funcionais sejam atendidos.
Na Engenharia de Software a fase de desenho da planta da construção civil corresponde à fase de design de software.
O objetivo do design de software é prover uma descrição da estrutura de funcionamento que servirá de base para a construção do software. Também pode ser entendido como a descrição da forma que o sistema terá quando estiver pronto para utilização. O termo descrição pode ser entendido como uma representação, que poderá ser textual ou gráfica.
Pfleeger (2004, p. 159) nos ensina que o design de software é o “processo criativo de transformar o problema em uma solução”. O design de software é, portanto, a descrição da estrutura a ser construída para que o software realize as
UNIDADE 2 | DESIGN E DESENVOLVIMENTO DE SOFTWARE
68
Componentes de software é um termo utilizado para designar um elemento de software que realiza determinadas funcionalidades. Este elemento pode representar uma unidade independente que em conjunto com outros componentes pode formar um software mais complexo ou um sistema. A utilização deste termo nesta unidade do Caderno de Estudos não possui relação com componentes visuais tipicamente disponíveis em algumas ferramentas de desenvolvimento.
UNI
Da mesma forma que a planta da casa é fundamental na sua construção, a arquitetura de software é a base que determinará os recursos que o software poderá oferecer. Um software monolítico terá características de recursos diferentes de um software orientado a serviços. No momento do design é necessário ter claro o que o software precisará para definir a arquitetura adequada.
2 TIPOS DE DESIGN
Em determinados momentos do processo de software há necessidade de utilização do design para comunicar como o software será construído para pelo menos dois públicos. O desenho do software pode ser utilizado para comunicação com o cliente/usuário ou com a equipe de desenvolvimento. São eles o design conceitual e o design técnico.
Caro acadêmico! Neste Caderno de Estudos o termo cliente/usuário é utilizado para designar os interessados em fazer uso do software.
UNI
O desenho que será utilizado na comunicação com o cliente/usuário é chamado de design conceitual e consiste num modelo mais superficial do software.
O modelo conceitual tem a finalidade de esclarecer ao cliente/usuário como o software desempenhará as funções necessárias. Este desenho pode ser utilizado como uma poderosa ferramenta para validação do entendimento dos requisitos do software.
O design conceitual descreve os limites, as entidades, atributos e relacionamentos do sistema. Esta descrição poderá responder a questões como (PFLEEGER, 2004):
TÓPICO 1 | DESIGN DE SOFTWARE
• De onde virão os dados?
• O que acontecerá com os dados no sistema?
• Qual será a aparência do sistema para os clientes/usuários?
• Que opções serão oferecidas para os clientes/usuários?
• Qual é a sequência de eventos?
• Como será a aparência dos relatórios e das telas?
Este modelo de design não deverá utilizar termos técnicos e não se concentra em detalhes técnicos. Não é objetivo deste design demonstrar como os dados serão manipulados pelos algoritmos ou de que forma serão armazenados.
Pfleeger (2004) sugere que um bom design conceitual deve ter as seguintes características:
• Ser escrito na linguagem do cliente/usuário.
• Não conter jargão técnico.
• Descrever as funções do sistema.
• Ser independente da implementação.
• Estar vinculado aos documentos de requisitos.
Portanto, o design conceitual deverá possibilitar ao cliente/usuário o entendimento do que o sistema fará, o que oferecerá de resultados e também esclarece as características externas observáveis do sistema.
Já o desenho que será utilizado na comunicação com a equipe de desenvolvimento é chamado de design técnico. Este modelo tem a finalidade de explicitar os componentes de software necessários para atender às necessidades do cliente/usuário. O design técnico pode compreender inclusive componentes de hardware que precisam ser considerados na construção da solução proposta.
No design técnico devem ser considerados diversos requisitos necessários à solução do problema do cliente/usuário. Estes requisitos podem incluir alguns elementos como:
• Configurações de hardware.
• Necessidades de software.
UNIDADE 2 | DESIGN E DESENVOLVIMENTO DE SOFTWARE
70
de telas ou formulários. As interfaces de comunicação do design de software são o formato de comunicação utilizado entre componentes de software.
Este formato de comunicação poderá, por exemplo, se referir ao nome da chamada de um procedimento remoto e os parâmetros que deverão ser informados. Ou ainda, dependendo da tecnologia e arquitetura utilizada, pode se referir à requisição de um serviço fornecendo parâmetros em formato XML (Extensible Markup Language).
3 ARQUITETURA DE SOFTWARE
Softwares que possuem grande conjunto de requisitos tipicamente são divididos ou decompostos em diversos subsistemas que oferecem o conjunto de serviços necessários para o software cumprir sua função. O processo de definição de quais serão estes subsistemas, os controles necessários e a comunicação de tais subsistemas são conhecidos como o projeto de arquitetura do software.
A arquitetura de software é, portanto, a estrutura de organização e divisão dos módulos que o compõem. Ela é dita como o conjunto de controles necessários para o adequado funcionamento harmonioso das partes e também a forma como estas partes se comunicam para cumprir com as funções necessárias.
A arquitetura de um software é um dos elementos mais importantes que deve ser definido no momento de sua construção. Tão importante quanto à definição é documentar adequadamente essa arquitetura. Bass et al. (1998), citado por Sommerville (2003), indica três vantagens de projetar e documentar explicitamente uma arquitetura de software:
• Comunicação com stakeholders: a documentação da arquitetura pode ser utilizada como uma representação do software para eventuais discussões.
• Análise de sistema: a documentação da arquitetura permite realizar análises sobre a possibilidade de o software poder ou não cumprir requisitos importantes como desempenho, confiabilidade e facilidade de manutenção.
• Reutilização em larga escala: um padrão de arquitetura pode ser utilizado para servir a um conjunto de softwares relacionados.
Cada arquiteto ou projetista de software pode utilizar diferentes enfoques para o processo de design de arquitetura, pois é uma atividade que tem forte dependência dos conhecimentos e habilidades do profissional. Independente da abordagem utilizada no processo de design da arquitetura, Sommerville (2003) destaca que as seguintes atividades são tipicamente comuns:
• Estruturação do sistema: é o processo de definição dos subsistemas que comporão o software e a comunicação existente entre eles.
• Modelagem de controle: é a definição de como será realizado o controle do relacionamento entre as partes do software.
TÓPICO 1 | DESIGN DE SOFTWARE
3 ARQUITETURA DE SOFTWARE
• Decomposição modular: é a definição da decomposição em módulos e as suas interconexões.
Tipicamente este conjunto de atividades é realizado de forma intercalada e pode ser realizado através de ciclos de refinamento. O nível de detalhamento dado dependerá da criticidade da necessidade de averiguar se o design de arquitetura permitirá ao software cumprir seus requisitos.
Em relação à arquitetura de software, a grande dúvida sobre o assunto está relacionada ao modelo ideal a ser adotado. Seria ótimo para os profissionais de software se houvesse um modelo arquitetural que solucionasse, por exemplo, a dificuldade de acompanhar a velocidade de evolução dos requisitos e os avanços das ferramentas de desenvolvimento.
Caso a arquitetura utilizada seja um modelo de software monolítico a rigidez poderá ser bastante alta. Já na utilização de uma arquitetura orientada a serviços (SOA – Service Oriented Architecture), a flexibilidade poderá ser bem maior. Porém isso poderá não ser verdade para todas as situações que um profissional de software possa enfrentar.
Há, sim, arquiteturas que facilitam o processo de integração de diferentes tecnologias e outras que são mais rígidas. Com o passar dos tempos é comum que diferentes modelos arquiteturais sejam utilizados e que de alguma forma estes coexistam, principalmente em softwares de grande porte.
Em relação aos impactos da arquitetura, Sommerville (2003) relata que ela afeta o desempenho, a robustez e a facilidade de distribuição e manutenção do software. Ele argumenta ainda que o modelo escolhido pode depender dos requisitos não funcionais do software, como:
• Desempenho: se o desempenho for um requisito importante, a arquitetura deverá considerar a necessidade de manter as operações mais importantes acopladas de maneira que ocorra o mínimo de comunicação possível entre subsistemas ou módulos.
• Proteção: um requisito de maior proteção exigirá que a arquitetura seja desenhada em camadas de forma a proteger as funções mais importantes em
UNIDADE 2 | DESIGN E DESENVOLVIMENTO DE SOFTWARE
72
encapsulados com menor granularidade para que possam ser rapidamente modificados. Uma boa prática é evitar o compartilhamento de estruturas de dados entre componentes.
Conforme você já estudou em outras partes desse Caderno de Estudos, não há modelo de solução universal e a “natureza força ao equilíbrio”. Independente da forma como isso seja dito, significa que quanto maior for a quantidade de requisitos do software, mais complexa poderá ser sua arquitetura.
Esta complexidade poderá ser exigida, por exemplo, pela existência de requisitos não funcionais conflitantes como desempenho e facilidade de manutenção. O requisito de desempenho pede que a arquitetura utilize componentes com maior granularidade, já a facilidade de manutenção pede a utilização de componentes com menor granularidade.
Uma forma simples para entender o conceito de granularidade é pensar num sistema monolítico. Um sistema monolítico possui a maior granularidade possível, ou seja, é composto de apenas um componente. Sistemas que possuem várias partes que se comunicam entre si são chamados de sistemas de menor granularidade.
A questão da granularidade é muito importante e deve ser devidamente considerada no momento do desenho da arquitetura. Softwares com granularidade baixa são mais flexíveis em termos de integração ou adição de módulos ou subsistemas, porém esta flexibilidade pode cobrar o preço de oferecer menor desempenho.
Esta redução no desempenho ocorre em parte pela sobrecarga (overhead) causada pela necessidade de comunicação entre diferentes componentes. Quanto maior for a quantidade de componentes que precisarem se comunicar para a realização de determinada função, maior será a sobrecarga e consequentemente menor será o desempenho.
É necessário observar que não podemos sacrificar a arquitetura exclusivamente em função do desempenho. O hardware disponível também poderá ser considerado na decisão e este está oferecendo cada vez mais poder de processamento e recursos acessíveis.
4 MODULARIDADE
No processo de definição do design mais adequado ao software, outra tarefa bastante árdua é a definição da modularidade. É uma tarefa árdua pelo fato de haver diversos fatores envolvidos na decisão da distribuição do software em módulos. Wassermann (1990), citado por Pfleeger (2004), indica que o design de um software seja criado com base em um dos seguintes modos:
TÓPICO 1 | DESIGN DE SOFTWARE
• Decomposição modular: utiliza como base a atribuição de funções aos componentes, descrevendo as funções que serão implementadas, como cada componente será organizado e como se relacionará com os demais componentes.
• Decomposição orientada a dados: nessa abordagem, as estruturas de dados externos são utilizadas para descrever como os dados estarão relacionados e quais dados serão envolvidos.
• Decomposição orientada a eventos: os eventos previstos, os possíveis estados de eventos, como eles modificam o estado do sistema e como as transformações de estados ocorrem são a base para esta abordagem.
• Design ‘outside-in’ (de fora para dentro): utilizam como base as entradas do usuário, o que é feito com estas entradas e as saídas que devem ser produzidas.
• Design orientado a objetos: utilizam as classes de objetos, descrição de cada tipo de objeto, atributos, métodos e o relacionamento entre as classes.
O design de software pode ser elaborado através de uma das abordagens descritas ou a partir da combinação de algumas dessas abordagens. A ideia central é utilizar uma hierarquia, aumentando o detalhamento a cada nível.
De acordo com Pfleeger (2004, p. 163), “dizemos que um sistema é modular quando cada atividade do sistema é realizada por exatamente um componente, e quando as entradas e saídas de cada componente são bem definidas”. Um componente bem definido é aquele em que todas as entradas são essenciais à sua função e todas as saídas são produzidas por uma de suas funções.
Esta abordagem permite ao profissional de software, neste caso, tipicamente denominado de arquiteto de software, utilizar o design para explicar características do software no nível de detalhes necessário. O arquiteto de software geralmente descreve o design de software de forma top-down ou botton-up.
Na forma top-down parte-se do todo para as partes, ou seja, é realizada uma decomposição do sistema em suas partes componentes. Já na forma botton-up ocorre o contrário, analisam-se as partes para compor o todo. Cada abordagem pode ser utilizada de acordo com o que há de informação disponível para a construção do novo software.
O nível de detalhamento do design dependerá de alguns fatores que
UNIDADE 2 | DESIGN E DESENVOLVIMENTO DE SOFTWARE
74
Conceitualmente pode-se entender que o design de software pode iniciar na arquitetura e descer para os demais níveis conforme necessário em cada projeto.
Na prática, o que se observa é que os arquitetos de software e até mesmo projetistas navegam entre estes níveis, à medida que entendem mais sobre a solução e as suas implicações.
5 DESIGN DE INTERFACES COM O USUÁRIO
O design de interface com o usuário pode iniciar na fase de requisitos para os casos em que há necessidade de explicitar algumas interfaces críticas da aplicação. Porém o maior volume de trabalho ocorre na fase de design. É nesta fase que as interfaces com o usuário são desenhadas.
Embora possa parecer simples, se considerarmos a importância que as interfaces com o usuários representam para um software, chegaremos à conclusão de que é uma atividade com grau de complexidade relativamente alto. Para o usuário convencional o software é aquilo que ele vê, ou seja, a interface.
Assumindo a premissa de que o usuário considera que o software é representado principalmente pelas suas partes visíveis, o seu design pode ser crítico para determinados projetos. Considerando esta importância, Marcus (1993), citado por Pfleeger (2004), indica que uma interface com o usuário deve abordar:
• Metáforas: elementos que podem ser reconhecidos e aprendidos.
• Modelo mental: organização e representação de elementos.
• Regras de navegação para o modelo: como se mover entre os elementos.
• Aspecto: aparência do sistema.
• Impressão: experiência do usuário.
O objetivo de considerar tais elementos é permitir que o usuário obtenha acesso rápido ao conteúdo que necessita, sem que perca a compreensão enquanto navega pelas informações. Para tal, podem-se utilizar diversos recursos tecnológicos como avatares, som, hipertexto, agentes, entre outros.
Para que a interface com o usuário possa oferecer uma experiência confortável e efetiva aos usuários do software, duas questões fundamentais devem ser consideradas em seu design: cultura e preferência (PFLEEGER, 2004).
Quando o software é desenvolvido para uso por uma grande diversidade de usuários que podem abranger o país ou quem sabe o mundo, é necessário que se considere diversos aspectos relacionados a este possível público. Os aspectos que devem ser considerados são as crenças, valores, normas, tradições, hábitos e até mesmo os mitos daqueles que utilizarão o software.
TÓPICO 1 | DESIGN DE SOFTWARE
5 DESIGN DE INTERFACES COM O USUÁRIO
No momento do design de interfaces com o usuário devem ser eliminadas quaisquer referências ou tendências culturais específicas, tornando a interface mais “imparcial” possível. Isso inclui a flexibilidade de tamanho das janelas de mensagens que podem variar de acordo com o idioma utilizado.
A internacionalização do dicionário do software deve permitir armazenar separadamente o texto e imagens para que seja mais fácil modificá-las.
As cores também podem ter significados muito relevantes. “Na Inglaterra, a cor púrpura representa a realeza, e, no Japão, púrpura significa dignidade e nobreza. Mas na Grécia antiga, púrpura simboliza a morte e o demônio”.
(FUKUDA, 1994 apud PFLEEGER, 2004, p. 175).
É importante observar que as questões culturais não são determinadas apenas pela nacionalidade, mas outros aspectos como área profissional, religião ou fatores da cultura da organização. Esta situação é uma representação clara de que é difícil para os desenvolvedores assumirem que entendem o que o cliente/
usuário quer.
Quando o software em desenvolvimento será utilizado por um grupo de usuários internos à organização, o nível de complexidade dessa tarefa se torna bastante menor. Ao atender a demandas internas, há maior controle e entendimento sobre este e outros aspectos que poderão causar impactos para os clientes/usuários.
Em relação aos aspectos de preferência, o nível de complexidade pode ser ainda maior, pois lida com uma gama mais ampla de possibilidades dentro de um público reduzido. As preferências podem incluir o tipo e tamanho da fonte utilizada no texto, os nomes dados às funções/opções do software e a distribuição das informações na interface.
O design de interface com o usuário pode ser realizado de maneira que se privilegiem os principais aspectos de cultura e preferência. Porém, acredita-se que não há um modelo de interface universal que possa ser aplicado a todas as culturas e que atenda a todas preferencias.
O desenvolvimento de interfaces com o usuário específicas para diversos
UNIDADE 2 | DESIGN E DESENVOLVIMENTO DE SOFTWARE
76
Do ponto de vista do usuário, “a interface é o software”, portanto, não podemos ignorar a relevância de seu design. Será que todos os projetistas e arquitetos de software tem dado a devida atenção a este assunto? Fica a questão para sua reflexão.
6 INDEPENDÊNCIA DOS COMPONENTES
É desejado que todo software desenvolvido seja estruturado de forma a facilitar o processo de manutenção. Um design de software para poder ser considerado bom deveria possuir as seguintes características (PFLEEGER, 2004):
• Facilidade de entendimento.
• Facilidade de implementação.
• Facilidade de realização de testes.
• Facilidade de modificação.
• Tradução correta dos requisitos em software.
A facilidade para realizar modificações é um aspecto altamente relevante, pois a manutenção é tipicamente de longo prazo. É relativamente comum encontrarmos casos de alterações em requisitos ou correção de defeitos exigirem que o design do software seja modificado para acomodar a mudança necessária.
Uma das formas de atender à boa parte das características do que é considerado um bom design é privilegiar a independência de componentes.
Desenhar software de maneira que os componentes sejam altamente independentes facilita o entendimento de como cada componente funciona.
A independência facilita o processo de modificação dos componentes, pois não causará impacto nos demais componentes. A identificação e isolamento de falhas, também se tornam mais simples. E a correção de falhas identificadas se torna uma atividade mais leve para os desenvolvedores.
Para o reconhecimento e medição do grau de independência dos componentes de um software são utilizados os conceitos de acoplamento e coesão.
Estes são conceitos que devem ser considerados na fase de design de qualquer software.
O conceito de acoplamento diz respeito ao grau de dependência entre componentes. Dois componentes possuem alto grau de acoplamento quando existe grande dependência entre eles. Quanto menor a dependência entre os componentes de um software, menor será seu grau de acoplamento.
A coesão está relacionada à parte interna da construção do componente, ou seja, na relação entre as partes de um componente. Um componente possui alto grau de coesão se todo seu código possui funcionalidades relacionadas à
TÓPICO 1 | DESIGN DE SOFTWARE
6 INDEPENDÊNCIA DOS COMPONENTES
realização da mesma tarefa e forem essenciais a ela. Quanto mais porções de código destinadas à realização de diferentes funções escritas no mesmo componente, menor será seu grau de coesão.
O design de software considerado ideal é aquele que possui baixo acoplamento e alta coesão. Você pode se perguntar: isso é a última tendência em termos de design de software instituída recentemente? A resposta é, não, essa é uma característica de design de software defendida desde a década de 1970.
Então, você pode se perguntar: por que os projetistas e arquitetos de software não consideram estes aspectos no design de seus softwares?
Fica a questão para sua reflexão. Provavelmente as respostas serão as mais
Fica a questão para sua reflexão. Provavelmente as respostas serão as mais