Baixado 27 vezes
![Visão de UC
(Modelo de Processo do Negócio)
Aluno não
matriculado
Requisita
matrícula
Comprovante
de Matrícula
Requisicao
Matricula
Avalia Requisicao de
Candidato
Efetua
matrícula
Candidato apto
Requisicao
Matricula
Efetua
matrícula
Avalia Requisição
de Aluno
Aluno
matriculado
Fim de período
Requisita
matrícula
Comprovante
de Matrícula
[ aluno apto? ]
[ aluno inapto? ]
Fulano : Aluno (from Criar Programa)Sistema (from Criar Programa)Candidato (from Criar Programa)](https://image.slidesharecdn.com/soft-arq-170303172725/85/Arquitetura-de-Software-12-320.jpg)
Carregado porFábio Nogueira de Lucena
Arquitetura de Software
Arquitetura de software é o nível de projeto que especifica a estrutura global de um sistema, incluindo subsistemas, camadas e elementos essenciais. O documento discute como produzir uma arquitetura de software inicial, incluindo análise de casos de uso, definição de organização de subsistemas e identificação de abstrações principais.
Mais conteúdo relacionado
Arquitetura de Software
- 1. Arquitetura de Software VisãoGeral Copyright © 2017 Fábio Nogueira de Lucena fabio@inf.ufg.br
- 2. O que éarquitetura de software? • Nível de projeto preocupado com • Questões além de algoritmos e estruturas de dados • Projeto e especificação a estrutura do sistema • Estrutura de controle global • Protocolos de comunicação, sincronização • Acesso a dados • Atribuição de funcionalidade a elementos de projeto • Distribuição física de elementos • Desempenho e escala
- 3. Onde obter maisinformações ... • ARQUITETURA DE SOFTWARE • Excelente ponto de partida: • www2.umassd.edu/SECenter/SAResources.html
- 4. O que nãoé? • Não é projeto “detalhado” • Não é projeto de algoritmos • Não é implementação • Não é o modelo de dados • Usa para assinatura de interfaces • Não é o sistema físico (processadores, rede, ...) • Usa para impacto de desempenho, confiabilidade, ... • Não é a arquitetura de hardware
- 5. Representação • Visão • Descriçãosimplificada de uma perspectiva • Construção civil • Planta baixa • Projeto elétrico • Projeto hidráulico, ... • Construção de software (segundo o RUP: “4+1”) • Visão de UC • Visão Lógica • Visão de processos • Visão de implementação • Visão de implantação
- 6. Visões de Arquitetura •Visão de Casos de Uso • Ucs e cenários que ilustram itens “arquiteturalmente significantes”, riscos técnicos, ... • Visão lógica • Classes + relevantes organizadas em subsistemas, packages e estes em camadas. Realizações de Ucs. • Visão de implementação • Organização de componentes, executáveis, fontes,... • Visão de processos • Configuração e interação entre processos e threads • Visão de implantação • Alocação de tarefas a nós físicos, interação entre estes
- 7. Arquitetura concentra-se ... •Na estrutura (subsistemas, camadas) • Nos elementos essenciais (UC críticos, classes principais, mecanismos comuns) • Em cenários principais (fluxo de controle principal por todo o sistema) • Em serviços (captura modularidade, elementos opcionais, ...) Visões de arquitetura são abstrações de todo o projeto
- 8. Por que éimportante? • Evolução do sistema • Reutilização da arquitetura ou parte • Avaliação de desempenho, disponibilidade, ... • Organização do trabalho de construção • Decisões acerca aquisição de componentes existentes • Inserção em um sistema maior
- 9. Como descrever emUML? • Visão lógica • Diagramas de classes, DTEs e diagramas de objetos • Visão de processos • Diagramas de classes e objetos (processos,threads) • Visão de implementação • Diagramas de componentes • Visão de implantação • Diagramas de implantação • Visão de casos de uso • Diagramas de ucs, atores, diagramas de seqüência.
- 10. Visão de Casode Uso • Fornece base para planejamento de iterações
- 11. Visão de UC(exemplo) Modelo de Processo do Negócio Casos de Uso Vision Document (SAD) Arquitetura do sistema conforme "percebida" pelos clientes. Atores
- 12. Visão de UC (Modelode Processo do Negócio) Aluno não matriculado Requisita matrícula Comprovante de Matrícula Requisicao Matricula Avalia Requisicao de Candidato Efetua matrícula Candidato apto Requisicao Matricula Efetua matrícula Avalia Requisição de Aluno Aluno matriculado Fim de período Requisita matrícula Comprovante de Matrícula [ aluno apto? ] [ aluno inapto? ] Fulano : Aluno (from Criar Programa)Sistema (from Criar Programa)Candidato (from Criar Programa)
- 13. Visão lógica • Basepara compreensão da estrutura e organização do projeto
- 14. Visão Lógica (exemplo) Presentation <<layer>> Data <<layer>> Business <<layer>> DataCapes (fromSoftware) Lattes (from Software) CAPES (from Logical View) CNPQ (from Logical View) Use-Case Realizations
- 15. Visão de processos •Base para compreensão da organização de processos NetScape 6.0 <<thread>> Internet Explorer 5.5 <<thread>> Apache Server (from Software) Browser <<thread>> 1 n1 n <<http>>
- 16. Refinamento da Visãode Processos CORBA Server (from Software) JVM (from Software) JMS broker (from Software) Java Plug-In 1.3 <<thread>> NetScape 6.0 <<thread>> Internet Explorer 5.5 <<thread>> Browser <<thread>> Apache Server (from Software) 1 n1 n <<http>> Database (from Software) 1 1 1 1 Servidor de Aplicação <<process>> 1 n 1 n Beans (from beans) <<thread>>
- 17. Visão de implantação •Base para compreensão da distribuição física do sistema entre nós Servidor SISPG preemptive Servidor Apache Banco de Dados Servidor de Aplicações Java Coordenação de Programa Laser Printer <<UFGNet>> Câmera Digital Impressão de DiplomasImpressora de Diplomas Navegante <<Internet>> Usuário <<Internet>> Servidor CCPFJ <<UFGNet>> <<UFGNet>>
- 18. Desenvolvimento de Arquitetura deSoftware • Como produzir uma arquitetura de software? • Como obter as visões de arquitetura? • Quando ocorre? • Quais as tarefas? • Qual o processo? • Quais os artefatos? • ...
- 19. Quando ocorre? • (após) Requisitos(gera entrada para A&P) • (início) Análise & Projeto • Transformar req em projeto • Obter uma arquitetura robusta • (durante) Fase de elaboração Concepção
- 20. Quais as tarefas? •Definir arquitetura candidata • Criar uma versão inicial da arquitetura • Definir elementos de arquitetura significantes • Definir camadas e organização do sistema • Definir realizações de casos de uso • Identificar classes de análise • Refinar a arquitetura • Identificar elementos de projeto daqueles de análise • Manter consistência e integridade da arquitetura • Descrever elementos de implantação e execução do sistema • Organizar o modelo de implementação
- 21.
- 22.
- 23. Definir arquitetura candidata •Compreende • Análise de arquitetura • Análise de casos de uso • Processo • Após início com a análise de arquitetura • Escolha casos de uso significantes • Realize a análise de casos de uso em cada UC • Atualize a arquitetura concomitantemente
- 24. Análise de Arquitetura •Desenvolver visão geral da arquitetura • Definir organização de subsistemas (high-level) • Identificar mecanismos de análise • Identificar abstrações principais • Criar realizações de casos de uso • Desenvolver modelo de implantação (high-level) • Revisar resultados 1Definirarquiteturacandidata INCLUI:
- 25. Análise de Casosde Uso • Suplementar descrições de casos de uso • Identificar classes de análise • Distribuir comportamento em classes de análise • Descrever responsabilidades • Descrever atributos e associações • Estabelecer associações entre classes • Descrever dependências de eventos entre classes • Avaliar resultados 1Definirarquiteturacandidata INCLUI:
- 26. Visão geral daarquitetura • Objetivo • Explorar e avaliar opções de arquitetura • Fornecer compreensão de alto nível da estrutura • Pode ser criada cedo (fase de concepção) • Reflete decisões e suposições acerca da implementação da Visão • Decisões acerca da arquitetura lógica e física • Ilustra “essência” da solução proposta • Fornece “grandes blocos” 1.1AnálisedeArquitetura
- 27. Exemplo (visão geralda arquitetura) Visão apresentada aos usuários 1.1.1AnálisedeArquitetura DataCapes (from Software) StrictoSensu <<subsystem>> LatoSensu <<subsystem>> Pi <<subsystem>> Financeiro <<subsystem>> CCPFJ <<sistema>> Lattes (from Software) Projetos <<subsystem>> CAPES CNPQ CCPFJ <<sistema>>
- 28. Definir organização desubsistemas • Objetivo • Criar estrutura inicial para o modelo de projeto • Modelo de projeto • Geralmente organizado em camadas • Neste ponto, focalize as camadas de aplicação e a camada específica ao negócio 1.1.1AnálisedeArquitetura
- 29. Visão Lógica (Top-Level) 1.1.1AnálisedeArquitetura Presentation <<layer>> Data <<layer>> Business <<layer>> DataCapes (fromSoftware) Lattes (from Software) CAPES (from Logical View) CNPQ (from Logical View) Use-Case Realizations
- 30. Visão Lógica (PresentationLayer) 1.1.1AnálisedeArquitetura Browser Java Applet HTTP <<provider>> (from Business) HTML Pages Server Pages (from Business) IIOP <<provider>> (from Business) JavaScript XML docs
- 31. Visão Lógica (BusinessObjects Layer) • Sabe-se que as interfaces CNPQ e CAPES são utilizadas por um subconjunto dos objetos • Na visão de implementação teremos componentes que implementam estas interfaces 1.1.1AnálisedeArquitetura
- 32. Visão Lógica (BusinessObjects Layer) 1.1.1AnálisedeArquitetura HTTP <<provider>> Web Server Server Pages Application Server <<provider>> IIOP <<provider>> JavaBeans Mapeamento Persistência (from Data) Business Objects CAPES (from Logical View) CNPQ (from Logical View)
- 33. Visão Lógica (DataLayer) 1.1.1AnálisedeArquitetura Persistência Mapeamento Persistência PostgreSQLInterbaseJDBC-Interbase JDBC-PostgreSQL
- 34. Identificar mecanismos deanálise • Identificação de padrões • Persistência, gerência de transação, ... • Identificar problemas possivelmente implícitos • Não diretamente fornece funcionalidade • Veja Design Patterns para detalhes. 1.1.1AnálisedeArquitetura
- 35. Exemplo (mecanismo deanálise) • Persistência (um mecanismo identificado) • Analysis Patterns Chapter 12 (Layered Architecture for Information Systems) Martin Fowler Addison-Wesley, 1997 • Object-Oriented Modeling and Design for Database Applications Chapter 13 (Relational Databases: Basics) Michael Blaha & Wiliam Premerlani Prentice-Hall, 1998 • Mostra como implementar modelos orientados a objetos com bancos de dados relacionais. 1.1AnálisedeArquitetura
- 36. Exemplo (observer pattern) •Objeto deve notificar outros sem conhecer quem são estes outros • Enviar e-mail após alteração, ... 1.1AnálisedeArquitetura
- 37. Identificar abstrações principais •Identificar classes de análise oriundas de ... • Requisitos • Glossário • Defina relacionamentos entre as classes • Em geral, vários diagramas são utilizados • Durante o projeto, tais classes sofrerão alterações Poderão se tornar “classes” • QUAL O OBJETIVO? • Identificar “conceitos principais” que o sistema manipulará • Ao analisar UCs outras classes e relacionamentos surgirão 1.1AnálisedeArquitetura
- 38. Exemplo (abstrações principais) 1.1AnálisedeArquitetura ItemCalendárioCalendário 1..n1..n Atividade ncreditos nome: String TipoDisciplina tipo Programa EstagioDocencia OutraAtividade descricao : String AreaConcentracao AtividadeCredito minimo maximo obrigatoria nome 1 n 1 n Estrutura Curricular 11 11 Disciplina ementa 1..n 1..n1..n 1..n Classifica nn Executa periodo conceito frequencia Aluno (from Academia) n nn n Requerimento Comprovante Documento Data : Date Diploma Certificado Informe DataInicio : Date DataFim : Date
- 39. Criar realizações decasos de uso • Para cada UC, crie realização do UC • O nome da realização deve ser o mesmo • Crie uma dependência da realização para o UC • É bom lembrar ... • UC especifica funcionalidade visível externamente • UC não fornece uma implementação • Colaboração descreve • Objetos que implementam o comportamento do UC • Forma que interagem para obter este efeito 1.1AnálisedeArquitetura
- 40. Exemplo (realizações deUCs) 1.1AnálisedeArquitetura Limpar base de informes (from Informes) Excluir informe (from Excluir informe) Excluir informe (from Informes) Editar informe (from Editar informe) Limpar base de informes (from Limpar base de informes) Criar informe (from Criar informe) Consultar informes (from Consultar informes) Consultar informes (from Informes) Criar informe (from Informes) Editar informe (from Informes)
- 41. Desenvolver modelo deimplantação • Objetivo • Visão da distribuição geográfica • Entendimento da complexidade operacional do sistema • Insumos • Usuários (localizações) • Dados do negócio • Especificação Suplementar • Requisitos não-funcionais • Restrições • Processo • Atender usuários, casos de uso, acesso a dados, ... 1.1AnálisedeArquitetura
- 42. Exemplo (diagrama deimplantação) 1.1AnálisedeArquitetura Servidor CCPFJ Servidor SISPG preemptive Servidor Apache Banco de Dados Servidor de Aplicações Java Coordenação de Programa Laser Printer <<UFGNet>> Câmera Digital Impressão de Diplomas <<UFGNet>> Impressora de Diplomas Navegante <<Internet>> Usuário <<Internet>> <<UFGNet>>
- 43. Classe de Análise •“Coisas” no sistema que possuem • Responsabilidade • Comportamento • Abstração de um papel • PAPEL: definição de comportamento e responsabilidade • Pode se referir a mais de um papel • Evolui em um ou mais elementos de projeto • Classes • Subsistemas 1.2AnálisedeUC
- 44. Classes de Análise(representação) • Boundary class • Interação entre ator e sistema • Control class • Comportamento específico de um ou mais UCs • Objetos que controlam outros objetos • Representa a dinâmica do sistema (fluxo de controle) • Entity class • Modela informação e comportamento associado
- 45. Classes de análise(exemplo) : Gerencia Informes : Elemento de Informação : Tela Informes: Usuário 1: Requisita informes 2: Obtem Informes 3: Obtem descrição 4: Mostra descrição de informes
- 46. Considerações finais • Arquiteturade software (item muito importante) • concepção e ELABORAÇÃO • Definição do “raio-x da organização do sistema” • Faz uso de várias visões • Orienta posteriores atividades de análise & projeto • Fase de Elaboração • Protótipo executável da arquitetura pode ser construído • Provavelmente na primeira iteração • Arquitetura estável deve ser atingida nesta fase