Page 1

Arquitetura Inserir Título Aqui Inserir de Software Título Aqui


Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Responsável pelo Conteúdo: Prof. Me. Wilson Vendramel

Revisão Textual: Prof.ª Dr.ª Luciene Oliveira da Costa Granadeiro


Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Nesta unidade, trabalharemos os seguintes tópicos: • Introdução; • Arquitetura de Software; • Modelo de Classes de Projeto.

Objetivos • Compreender a importância da arquitetura de software no processo de desenvolvimento de sistemas de software; • Entender a transformação de classes de análise para classes de projeto e a representação dos modelos, utilizando notações de modelagem UML.

Caro Aluno(a)! Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o último momento o acesso ao estudo, o que implicará o não aprofundamento no material trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas. Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns dias e determinar como o seu “momento do estudo”. No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões de materiais complementares, elementos didáticos que ampliarão sua interpretação e auxiliarão o pleno entendimento dos temas abordados. Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e aprendizagem. Bons Estudos!

Fonte: iStock/Getty Images

• Agilidade e Arquitetura;


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Contextualização O projeto (design) de arquiteturas de software contendo componentes distribuídos na Web pode ser bastante complexo. Diante desse cenário, é necessário que arquitetos de software projetem arquiteturas que favoreçam o desenvolvimento de sistemas escaláveis, manuteníveis, interoperáveis, portáveis, reutilizáveis e que não comprometam seu desempenho. Por que a arquitetura de software é importante? O que um arquiteto de software faz? Quais as habilidades que um arquiteto de software deve ter?

Antes de iniciar o estudo desta unidade, leia uma publicação interessante da Microsoft Developer Network (MSDN) a respeito de arquitetura de software. O texto está disponível em: https://goo.gl/L481os.

6


Introdução Este material teórico apresenta a importância da arquitetura de software no processo de desenvolvimento de sistemas de software e a transformação de classes de análise para classes de projeto. Para facilitar a compreensão da transformação das classes, serão utilizadas notações da Unified Modeling Language (UML), especificamente o diagrama de classes. É importante salientar que o objetivo deste material não é explicar em detalhes os conceitos de programação orientada a objetos, nem as notações dos diagramas da UML, mas aplicar os referidos conceitos no contexto da disciplina de arquitetura de software.

Arquitetura de Software Quando nós estudamos arquitetura de software, é muito difícil não elencar o importante livro Software Architecture in Practice de Bass, Clements e Kazman (2003). Diversos autores de livros de Engenharia de Software, incluindo Pressman e Maxim (2016), citam os referidos autores em suas obras.

Fazendo uma analogia rápida, faça um esboço da arquitetura de um edifício. Quais são os elementos dessa arquitetura? Pressman e Maxim (2016) consideram que, quando pensamos na arquitetura de um edifício, nós mentalizamos diversos atributos. De forma geral, nós pensamos na estrutura física, porém, a arquitetura vai muito além disso. A arquitetura é o modo pelo qual os vários componentes do edifício são integrados para formar um todo consistente; é como o edifício se ajusta ao seu ambiente e se integra a outros edifícios da vizinhança; é o nível com que o edifício alcance seu objetivo declarado e satisfaça às necessidades de seu proprietário; é o lado estético da estrutura (impacto visual) e como texturas, cores e materiais, são combinadas para criar a fachada e o ambiente interno; é pensar nos detalhes (iluminação, tipo de piso, posicionamento dos painéis etc.). A arquitetura é arte. E quanto à arquitetura de software, o que é essa arquitetura que tanto nos interessa? A arquitetura de software é a estrutura do sistema de software, que especifica e mostra os componentes do software, as propriedades visíveis externamente e como elas se relacionam entre si. A arquitetura de software é influenciada e modificada com o decorrer do tempo pelos requisitos de negócio, ambiente de desenvolvimento e evolução das características técnicas (BASS, CLEMENTS e KAZMAN, 2003). Para Pressman e Maxim (2016), a arquitetura não é o software em si, mas uma representação que possibilita analisar a efetividade do projeto no atendimento dos requisitos, considerando alternativas de arquitetura, em um estágio em que realizar mudanças

7

7


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

de projeto ainda é relativamente simples, e diminuindo os riscos relacionados com a construção do sistema de software. Essa definição destaca o papel dos componentes de software em qualquer representação de arquitetura. Um componente de software é uma unidade que existe em tempo de execução, que pode ser utilizada na construção de diversos sistemas e que, havendo necessidade, pode ser substituída por outra unidade que tenha a mesma funcionalidade. Um componente provê acesso aos seus serviços por meio de uma interface. Quando o componente é construído de acordo com paradigma orientado a objetos, ele é composto por vários objetos. Portanto, a interface do componente é constituída de um ou mais serviços que as classes dos referidos objetos implementam (BEZERRA, 2015). Uma arquitetura de software bastante conhecida na Web é a arquitetura cliente-servidor em multicamadas, pois suporta a execução de aplicações de grande porte com centenas ou milhares de clientes e nas quais os dados e a aplicação são voláteis e integrados a dados oriundos de diversas bases de dados. Para Sommerville (2011), em uma arquitetura cliente-servidor em multicamadas, as diferentes camadas do sistema de software, chamadas apresentação, processamento de aplicação e gerenciamento de dados, e processamento de banco de dados são processos separados que podem ser executados em distintos nós de processamento. Essa arquitetura pode evitar problemas de escalabilidade e desempenho, ou até mesmo problemas de gerenciamento do sistema de software. A figura 1 apresenta um exemplo de arquitetura em multicamadas de um Sistema de Internet Banking.

Figura 1 – Exemplo de uma arquitetura em multicamadas Fonte: Sommerville, 2011

Apenas para exemplificar uma representação de arquitetura de software utilizando notações UML, a figura 2 mostra um exemplo de uma arquitetura em multicamadas de um Sistema de Gestão Acadêmica por meio de um diagrama de implantação, alocando os componentes de software em seus devidos nós de processamento, exibindo os relacionamentos entre si. Não se preocupe ainda com os detalhes dessa figura porque os devidos conceitos serão explicados nas unidades posteriores desta disciplina.

8


Figura 2 – Diagrama de implantação com alocação de componentes Fonte: Bezerra, 2015

Bass, Clements e Kazman (2003) apresentam três aspectos que enfatizam a importância da arquitetura de software: 1. A arquitetura de software fornece uma representação que facilita a comunicação entre todos os envolvidos; 2. A arquitetura de software evidencia as decisões de projeto que terão impacto no trabalho de engenharia de software; 3. A arquitetura de software estabelece um modelo relativamente simples e compreensível de como é a estrutura do sistema e como seus componentes trabalham conjuntamente.

Links úteis sobre arquitetura de software podem ser encontrados em: https://goo.gl/NjnjHz.

Arquitetura de Software no Processo de Desenvolvimento Antes de entender a importância da arquitetura de software no desenvolvimento de software, vamos recordar o que é um processo de software. De acordo com Sommerville (2011), processo de software é um conjunto estruturado de atividades necessárias para desenvolver um sistema de software. Há diversos processos de desenvolvimento de software, mas todos envolvem pelo menos: 1. Especificação: aquilo que o sistema deve fazer; 2. Projeto e Implementação: como o sistema será estruturado e implementado; 3. Validação: como o sistema será validado para saber se ele faz aquilo que o cliente deseja; 4. Evolução: como o sistema será evoluído em resposta às mudanças vindas das necessidades do cliente.

A fase de Projeto e Implementação transformam a especificação do sistema em um sistema de software executável. Independentemente do modelo de processo de software escolhido para desenvolver o sistema, essa fase é de extrema importância para o projeto de arquitetura de software.

9

9


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

A figura 3 apresenta o modelo cascata que é um modelo de processo de desenvolvimento de software. Nós sabemos que esse modelo é dirigido a planos, em que todas as atividades do processo são planejadas com antecedência e o progresso é medido em relação a esse plano, diferentemente de um processo ágil, em que o planejamento é iterativo e incremental, sendo mais simples adequar o processo para atender às mudanças nos requisitos do cliente.

Figura 3 – O modelo cascata Fonte: Sommerville, 2011

Você pode perguntar: “por que esta unidade apresenta o modelo cascata?”. É fato que a abordagem desse modelo é nitidamente sequencial, mas se você analisar bem, uma iteração também é uma sequência de atividades. Talvez as grandes diferenças estejam no planejamento das atividades, no tempo de entrega do produto de software e na forma de responder às mudanças dos requisitos. De qualquer forma, é interessante você saber que há processos de software que combinam atividades de processos dirigidos a planos e processos ágeis, uma espécie de processo de desenvolvimento híbrido.

Não existe processo de software certo ou errado, mas um processo adequado ou inadequado para cada situação. Mas o objetivo deste material não é discutir as diferenças entre modelos de processo dirigidos a planos e modelos de processo ágeis. O motivo da escolha inicial pelo modelo cascata é pela representação explícita de suas fases. Perguntamos a você: onde a arquitetura de software é projetada no modelo apresentado na figura 3? Vale ressaltar que a arquitetura de software pode ser abordada em todas as fases apresentadas na figura 3, mas o projeto de arquitetura de software é realizado na fase de Projeto de Sistema e Software. Por quê? Para Sommerville (2011), as atividades de projeto e implementação de software convertem a especificação de sistema em um sistema executável. Enquanto o projeto se

10


preocupa com o design de estrutura do software que concretiza a especificação, a implementação transforma essa estrutura em um sistema executável. Essas atividades estão interligadas e podem ser intercaladas.

Nós precisamos tomar cuidado ao utilizar a palavra projeto. Apesar de a tradução mais comum dessa palavra para a língua inglesa ser project, aqui nós utilizaremos a tradução design. Se você estiver fazendo referência à gestão de um projeto de desenvolvimento de sistema de software, você está se referindo ao projeto como um todo, isto é, ao termo project. No contexto desta disciplina, nós estamos nos referindo ao projeto da estrutura do sistema de software, incluindo projeto de arquitetura, projeto de interface, projeto de componentes, projeto de banco de dados, isto é, estamos nos referindo ao termo design. A figura 4 apresenta um modelo geral do processo de design de sistema de software (SOMMERVILLE, 2011). As entradas do projeto alimentam as atividades de projeto. Mas o que é feito em cada uma dessas atividades? 1. Projeto de arquitetura: a estrutura geral do sistema é projetada, inclusive os componentes principais (às vezes, chamados de subsistemas ou módulos), seus relacionamentos e como são distribuídos; 2. Projeto de interface: as interfaces entre os componentes do sistema são projetadas; 3. Projeto de componente: cada componente do sistema é projetado para operar separadamente; 4. Projeto de banco de dados: as estruturas de dados do sistema são projetadas e como essas serão representadas no banco de dados.

Figura 4 – Modelo geral do processo de design Fonte: Sommerville, 2011

11

11


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Ainda sobre a figura 4, cada atividade de projeto resulta em uma saída de projeto. O projeto de arquitetura resulta na arquitetura de sistema; o projeto de interface resulta na especificação de interface; o projeto de componentes resulta na especificação de componentes e o projeto de banco de dados resulta na especificação de banco de dados. Todas essas saídas (especificações) compõem o projeto (design) de arquitetura de software.

Agilidade e Arquitetura Na visão de alguns, os processos ágeis descartam totalmente a documentação de software. Não é isso que o Manifesto Ágil diz. Sobre isso, o que o referido manifesto diz é que o software funcionando tem mais valor do que documentação abrangente.

O manifesto para o desenvolvimento ágil de software pode ser acessado em: https://goo.gl/NyD39z. Para Pressman e Maxim (2016), há pessoas do desenvolvimento ágil que equipara o projeto arquitetural do software a um “projeto inicial grande”, levando à documentação e implementação de funcionalidades desnecessárias. Entretanto, a maioria dos desenvolvedores ágeis concorda que é importante enfatizar a arquitetura do software em sistemas complexos (quando apresentam muitos requisitos, vários envolvidos, ou ampla distribuição geográfica), havendo, assim, a necessidade de integrar práticas de design arquitetural aos modelos de processo ágeis. Para tomar decisões arquiteturais no início e evitar o retrabalho e/ou problemas de qualidade quando a arquitetura errada é adotada, os desenvolvedores ágeis devem antecipar as questões arquiteturais a partir de uma coleção emergente de histórias de usuário. Havendo um protótipo arquitetural e elaborando artefatos arquiteturais explícitos para se comunicar com envolvidos, um time ágil pode atender a necessidade de um projeto arquitetural. O desenvolvimento ágil propicia aos arquitetos de software possibilidades para trabalharem em conjunto com as equipes técnicas e de negócio, a fim de dar o caminho para um bom projeto de arquitetura de software. Por exemplo, um modelo de processo híbrido que combine Scrum, eXtreme Programming e Gestão de Projetos, permite fazer um planejamento inicial que define o rumo da arquitetura, podendo esta ser adequada para uma história de usuário. Durante a escrita das histórias de usuário, o arquiteto de software escreve histórias de usuário arquiteturais para o produto de software e trabalha em conjunto com o Product Owner (PO) para priorizá-las com as histórias de usuário de negócio, de acordo com o planejamento dos sprints. O arquiteto trabalha com o time durante o sprint para garantir que o sistema de software em desenvolvimento apresente alta qualidade arquitetural. Se a qualidade é alta, o time continua desenvolvendo o sistema por conta própria. Caso contrário, o arquiteto se junta ao time durante o sprint. Após o término do sprint, o arquiteto avalia a qualidade do sistema, antes do time apresentar aos envolvidos (stakeholders) em uma reunião de revisão. Como projetos ágeis exigem a entrega

12


iterativa de artefatos a cada sprint, incluindo a documentação da arquitetura do software, é possível verificar os artefatos e o código, tornando-se uma forma útil de revisão da arquitetura. A adoção de um processo compatível com a filosofia ágil assegura a qualidade da arquitetura de software.

Assista a um vídeo interessante sobre Metodologias Ágeis versus Documentação, disponível em: https://youtu.be/3Smbhnmue7Y.

Modelo de Classes de Projeto Ao estudar modelagem de sistemas de software orientados a objetos, você estará modelando principalmente classes e objetos, que são conceitos fundamentais do paradigma orientado a objetos. Além desses conceitos, o paradigma ainda é formado por princípios como encapsulamento, herança, polimorfismo e composição. Tais princípios precisam ser abstraídos para poderem ser representados em um modelo de classes. O paradigma orientado a objetos faz uso intensivo de abstrações.

Conhecer uma linguagem orientada a objetos (Java, C++, C#...) é um primeiro passo necessário, mas insuficiente para criar sistemas de software orientados a objetos. “Saber pensar em termos de objetos” é essencial (LARMAN, 2007). Para Bezerra (2015), a abstração é um processo mental pelo qual nós selecionamos os aspectos mais importantes (relevantes) e ignoramos os menos importantes de alguma coisa. Esse processo permite gerenciar a complexidade de um objeto, possibilitando se concentrar nas características essenciais do mesmo. A abstração de algo depende da perspectiva sobre a qual uma coisa é analisada, sendo que o que é relevante para um, dentro de um contexto, pode não ser importante para outro. A figura 5 mostra os princípios da orientação a objetos que podem ser vistos como aplicações do princípio da abstração.

Figura 5 – Princípios da Orientação a Objetos Fonte: Bezerra, 2015

Esta unidade não tem o propósito de explicar cada um desses princípios isoladamente, mas vale ressaltar que os referidos princípios também podem ser representados em um modelo de classes de projeto.

13

13


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Mas, afinal, o que é um modelo de classes de projeto? O modelo de classes de projeto é o resultado de refinamentos no modelo de classes de análise, visto que o modelo de classes de projeto é construído paralelamente com o modelo de interações. A construção do modelo de interações gera informações para a transformação do modelo de classes de análise no modelo de classes de projeto. O modelo de classes de projeto possui detalhes para a implementação das classes (BEZERRA, 2015). A construção paralela do modelo de classes de projeto com o modelo de interações permite o arquiteto de software ter duas visões diferentes que se complementam: a visão estrutural e a visão comportamental do projeto do sistema de software. Talvez você esteja se perguntando. O que é o modelo de interações? Os diagramas de sequência e de colaboração, por exemplo, são diagramas que compõem o modelo de interações. Vale destacar que as funcionalidades de um sistema de software orientado a objetos são realizadas internamente por meio de colaborações entre objetos. Enquanto os atores visualizam externamente resultados de cálculos, relatórios produzidos, confirmações de requisições realizadas etc., os objetos internamente colaboram uns com os outros para produzir tais resultados. Essa colaboração pode ser vista sob o aspecto comportamental e dinâmico e sob o aspecto estrutural e estático (BEZERRA, 2015). A UML possui dois grupos de diagramas, sendo um para representar os aspectos estruturais e o outro para representar os aspectos comportamentais do sistema de software. Para você ter uma visão melhor, a figura 6 apresenta os diagramas definidos pela UML. Observe que o diagrama de classes, o diagrama de objetos e o diagrama de pacotes são exemplos de diagramas estruturais, e o diagrama de casos de uso, o diagrama de transições de estados e os diagramas de interação são exemplos de diagramas comportamentais. Observe ainda que o diagrama de sequência e de colaboração são exemplos de diagramas de interação.

Figura 6 – Diagramas UML Fonte: Bezerra, 2015

14


O diagrama de classes representa o aspecto estrutural e estático dos objetos que compõem um sistema de software orientado a objetos. Esse diagrama evolui ao longo do processo de desenvolvimento de software, significando que, conforme o sistema de software é desenvolvido, o diagrama de classes é evoluído com novos detalhes. Há três níveis sucessivos de detalhamento do modelo de classes: análise, projeto e implementação. O modelo de classes de análise representa as classes de domínio (negócio), não se preocupando com restrições associadas à tecnologia a ser utilizada na solução de um problema. O modelo de classes de projeto é elaborado a partir da adição de detalhes ao modelo anterior conforme a solução de software escolhida. Por fim, o modelo de classes de implementação corresponde à implementação das classes em alguma linguagem de programação (BEZERRA, 2015). Tanto o modelo de análise quanto o de projeto podem ser representados por diagramas de classes da UML. Quando você analisa requisitos, casos de uso ou histórias de usuário visando abstrair objetos para elaborar um diagrama de classes, o primeiro modelo tende a ser o diagrama de classes de análise. O propósito desse diagrama é representar o problema a ser resolvido pelo sistema de software, modelando conceitos do domínio de negócio, sem se preocupar com características técnicas da solução para resolver o problema. Mesmo assim, é importante entender que o diagrama de classes de análise é a base para construir o diagrama de classes de projeto. Lembre-se de que o diagrama de classes de projeto resulta do aprimoramento do diagrama de classes de projeto, sendo que o propósito deste último é representar os detalhes da solução do problema.

O diagrama de classes de análise é construído a partir da especificação dos requisitos do software. O foco está na representação do problema a ser solucionado. O diagrama de classe de projeto é construído a partir do diagrama de classes de análise. O foco está na representação da solução do problema. As classes de projeto são utilizadas como base para a implementação do sistema de software. A análise e projeto são fases do processo de desenvolvimento de software. De acordo com Larman (2007), a fase de análise se preocupa com uma investigação do problema e dos requisitos, enquanto que a fase de projeto está preocupada com uma solução conceitual que atenda aos requisitos e não sua implementação, como, por exemplo, o projeto de um banco de dados ou das classes de objetos. É importante ressaltar que os projetos podem ser implementados, por exemplo, em código, uma vez que a implementação representa o verdadeiro e completo projeto realizado. Em se tratando de análise e projeto orientado a objetos, a análise orientada a objetos enfatiza a abstração e a descrição dos objetos (conceitos) do domínio do problema. Um sistema de software de voo, por exemplo, tem os objetos voo, avião e piloto. O projeto orientado a objetos enfatiza a definição dos objetos de software e como eles colaboram para satisfazer os requisitos. Um objeto de software avião pode ter seus atributos e métodos especificados. Por fim, durante a programação (implementação) orientada a objetos, os objetos do projeto são implementados, como, por exemplo, a classe avião na linguagem Java (LARMAN, 2007).

15

15


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Supondo que você tenha dois projetos de desenvolvimento de sistema de software (A e B). O diagrama de classes de análise do Projeto A tem 30 classes. Ao construir o diagrama de classes de projeto (design) a partir desse diagrama de classes de análise, o refinamento resultou em um diagrama de classes de projeto com 15 classes. O diagrama de classes de análise do Projeto B tem 30 classes. Ao construir o diagrama de classes de projeto (design) a partir desse diagrama de classes de análise, o refinamento resultou em um diagrama com 45 classes. Qual dos dois projetos tem mais consistência? O Projeto A que apresentou uma redução de classes ou o Projeto B que teve um aumento de classes? Antes de responder à pergunta, vamos relembrar os objetivos de cada um dos diagramas de classes. O diagrama de classes de análise é construído a partir da especificação do projeto (requisitos, casos de uso, histórias de usuário etc.), portanto, o referido diagrama reflete o problema a ser resolvido a partir de uma visão de análise do domínio de negócio. Já o diagrama de classes de projeto (design) é um refinamento do diagrama de classes de análise. É possível que você associe refinamento com redução/sintetização das classes, mas, na verdade, o refinamento está associado ao aprimoramento/aperfeiçoamento/melhoria das classes, resultando em novos elementos no diagrama de classes. Pense bem sobre a pergunta feita. No Projeto A, a redução de 15 classes do diagrama de classes de análise significa que a fase de análise não foi bem realizada, pois 50% das classes de análise foram eliminadas, lembrando que as classes de análise são oriundas da especificação do projeto. Já no Projeto B, o aumento de 15 classes no diagrama de classes de projeto (design) elaborado a partir do diagrama de classes de análise, mostra que houve um aprimoramento no diagrama de classes na fase de projeto, pois um diagrama de classes de projeto é composto pelas classes de negócio (análise) e também pelas classes de software, que são classes com características de design. Respondendo à pergunta: de acordo com o que foi explanado, o Projeto B é mais consistente do que o Projeto A porque se espera um aumento do número de classes na fase de projeto, não uma redução. Por que o número de classes aumenta na fase de projeto? Na fase de projeto, são considerados outros aspectos, além das classes de negócio, tais como: novos elementos necessários para a construção do diagrama de classes de projeto; transformações pelas quais passam as classes e suas propriedades com o objetivo de transformar o modelo de classes de análise no modelo de classes de projeto; adição de novas classes ao modelo; especificação de atributos, operações e de associações; refinamentos e conceitos relacionados à herança que surgem durante a modelagem de classes de projeto; classes abstratas, interfaces, polimorfismo e padrões de projeto (design patterns) (BEZERRA, 2015).

Classe de análise: também é chamada de classe de negócio, ou de classe de domínio. Classe de projeto: também é chamada de classe de design, ou de classe de especificação. Domínio de negócio: também é chamado de domínio do problema, ou de domínio da aplicação.

16


Vamos, agora, exemplificar a transformação das classes de análise para classes de projeto (design), utilizando notações UML. Para tal, vamos trabalhar com a abstração de um projeto de sistema de software de locadora de carros. Você recebeu uma especificação textual de um caso de uso denominado “Alugar Carro”. Ao analisar o referido caso de uso, você abstraiu inicialmente os objetos (conceitos) locação, carro e cliente com alguns de seus respectivos atributos.

Maiores informações sobre a UML podem ser encontradas em: https://goo.gl/WmotPG. A figura 7 apresenta uma versão do diagrama de classes de análise para agrupar os objetos abstraídos. Observe que este diagrama de classes enfatiza os objetos (conceitos) do domínio de negócio e os relacionamentos de associação entre si com suas devidas multiplicidades. Inclusive, nem é necessário você construir este diagrama numa ferramenta específica para modelagem de notações UML.

Figura 7 – Diagrama de Classes de Análise Fonte: Acervo do Conteudista

A figura 8 apresenta um diagrama de classes de projeto a partir do refinamento do diagrama de classes de análise mostrado na figura 7. Observe que este diagrama de classes enfatiza os objetos de software e como eles colaboram para atender o caso de uso, incluindo a navegabilidade nos relacionamentos de associação, possibilitando compreender o objeto remetente de mensagens e os objetos receptores. Além disso, as classes exibem os atributos e métodos especificados com seus tipos e a devida visibilidade. Como o diagrama de classes de projeto apresenta um maior detalhamento, é interessante utilizar uma ferramenta específica para modelagem de diagramas UML.

Figura 8 – Diagrama de Classes de Análise Fonte: Acervo do Conteudista

Obviamente, um diagrama de classe de projeto não se concentra apenas na transformação das classes de análise para classes de design. Conforme já apresentado anteriormente, outros aspectos devem ser considerados nesse diagrama. Portanto, conceitos como classes abstratas, interfaces e padrões de projeto serão abordados nas próximas unidades desta disciplina.

17

17


UNIDADE

Arquitetura no Desenvolvimento de Software e Modelo de Classes de Projeto

Material Complementar Indicações para saber mais sobre os assuntos abordados nesta Unidade: Sites

Software Architecture Links https://goo.gl/r8GVhR

O Que é Arquitetura de Software? https://goo.gl/RoCXrZ

Unified Modeling Language https://goo.gl/G4MqYX

Manifesto Para o Desenvolvimento Ágil de Software https://goo.gl/ZeQPC4

Vídeos

Métodos Ágeis e Documentação de Software https://youtu.be/3Smbhnmue7Y

18


Referências BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. Addison-Wesley, 2003. BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3.ed. São Paulo: Elsevier, 2015. LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3.ed. Porto Alegre: Bookman 2007. PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre: AMGH, 2016. SOMMERVILLE, I. Engenharia de software. 9.ed. São Paulo: Pearson, 2011.

19

19


Arquitetura de Software - Teste  
Arquitetura de Software - Teste  
Advertisement