00 Parte 00 - Todos os slides disciplina ESI2-2019-1

SAVE OFFLINE

Engenharia de Software 2 Prof. Michel Soares

Sobre o professor • Prof. Dr. Michel Soares • [email protected]

Nova Grade Curricular • Nova ementa • 50% de teoria e 50% de práticas – maior ênfase nas atividades práticas e no Projeto em equipe

Ementa da disciplina • • • • • • • • • •

Introdução ao Projeto de Software. Linguagens de Modelagem (Artefatos de Projeto). Projeto de Software (Alto Nível e Detalhado). Arquitetura de Software. Estilos Arquiteturais e Padrões de Arquitetura. Padrões de Projeto. Projeto de Interface. Projeto de Banco de Dados. Implementação e Geração de Código. Gerência de Configuração de Software. Implantação de Sistemas. Ferramentas. Estudo de Casos. Projeto Prático.

Carga horária • 50% horas teóricas • 50% horas práticas

Pré-requisitos da disciplina • Engenharia de Software 1 – Processos, ciclo de vida, boas propriedades de software (coesão, acoplamento, hierarquização, modularidade, information hiding, objetos, herança, requisitos de software, casos de uso, ...)

• Noções de Sistemas distribuídos • Banco de dados – Criação de tabelas, Inserção em tabelas, SELECTs

• Programação Orientada a Objetos – C++, Java, C#

Pré-requisitos da disciplina - Ferramentas • Gerenciador de versões – GIT, ...

• Editor de código – NetBeans, Eclipse, ...

• Modelagem UML – Astah, Poseidon, StarUML, Rational Rose, Visio, ...

Horários e salas de Aula • 6.as – 13:00 as 16:20 – DID 3 - 116

• Evitem chegar atrasados

Dias de aulas • • • • •

Maio – 03, 10, 17, 24, 31 Junho – 7, 14, 21, 28 Julho – 05, 12, 19, 26 Agosto – 02, 09, 16, 23, 30 Setembro – 06

• Aulas teóricas e exercícios, Provas, devolução de provas, práticas, seminário

Datas importantes – a verificar • Provas – – – –

P1 – 31 de maio P2 – 05 de julho P3 – 16 de agosto Substitutiva – 06 de setembro

• Vista e devolução de provas – 30 de agosto (P1, P2, P3)

• Seminário sobre o projeto – 23 de agosto

• Práticas: – – – –

24 de maio 28 de junho 02 de agosto 09 de agosto

Práticas • Reunião obrigatória com os grupos na minha sala – Acompanhamento dos projetos • Dúvidas • Correção de modelos • Arguição sobre a participação individual

• Dúvidas sobre a disciplina • Teóricas • Exercícios

• Trabalho em equipe • Aproveitem o tempo para reunir os grupos

Práticas - Seminários • 23 de agosto de 2019 • Apresentação do projeto – Projeto do Software – Software executável

Formato da Avaliação • 3 avaliações teóricas • Questões abertas e testes • 1 avaliação substitutiva – Para quem perdeu 1 avaliação (por qualquer motivo) – Para quem não conseguiu nota mínima de aprovação após 3 avaliações, substitui 1 avaliação

Formato da Avaliação • Cada prova vale no mínimo 6 pontos • A cada prova, o trabalho vale até 4 pontos • A nota do trabalho será individual • Ex.: a unidade valerá 10 pontos, sendo: – 6 pontos de uma prova teórica, individual – 4 pontos do trabalho, com nota individual

Como será a nota do trabalho ? • A cada etapa, o grupo receberá uma nota N, entre 0 e 4. • Cada aluno será arguido sobre sua contribuição • A nota será individual - uma porcentagem da nota do grupo, variando de 0 a 100%

Nota Individual do trabalho • • • •

0% - não fez nada 30% - ajudou um pouco 70% - ajudou quase sempre 100% - ajudou sempre e fez todas as tarefas alocadas pelo grupo/líder

•  Só funciona se todos forem honestos em relação a sua participação efetiva

Exemplo de nota • • • • •

Grupo: nota na unidade foi 3,5 em 4 Aluno1: 70%  3,5*0.7 = 2,45 Aluno2: 100%  3,5*1.0 = 3.5 Aluno3: 0% (nada contribuiu)  3,5*0 = 0 Aluno4: 30%  3,5*0.3 = 1,05

• Cada nota individual será somada à nota da prova

Exemplo de nota de cada prova • Aluno1: 70%  3,5*0.7 = 2,45 – Prova: 4,9 + 2,45 = 7,35

• Aluno2: 100%  3,5*1.0 = 3.5 – Prova: 6 + 3,5 = 9,5

• Aluno3: 0% (nada contribuiu)  3,5*0 = 0 – Prova: 2,7 + 0 = 2,7

• Aluno 4: 30%  3,5*0.3 = 1,05 – Prova: 5 + 1,05 = 6,05

O trabalho é obrigatório?

• Não • Mas vale até 40% da nota

Horários das Avaliações • • • • •

Início: 13:00 Término: 16:00 Sem intervalo Evitem chegar atrasados Após alguém sair da sala, ninguém mais entra!

Vista e Devolução de provas • Vista e Devolução de todas as provas – 30 de agosto – Local: Sala 22 do DCOMP – Horário: 13:00 as 16:00

• Não haverá outra oportunidade em hipótese alguma • Temos apenas 1 dia de aula na semana

Apresentação dos projetos • 23 de agosto • Grupos apresentam o software e o projeto • Parte da Avaliação final da 3.a prova

Horários de Atendimento • Quintas-feiras – Terças e quintas: • 13:30 as 14:45

• Obs.: eventualmente poderei estar em reuniões (CCET, PROCC, DCOMP, Colegiado de EC) ou em alguma atividade administrativa em algum desses horários • Outros horários: são bem vindos, desde que seja possível no momento.

Avaliação substitutiva • 1 única avaliação, que substitui apenas uma das avaliações • Conteúdo total – Independente de por qual motivo o aluno tenha perdido a prova – Data: 06 de setembro

• Vale de 0 a 10, sem a nota do projeto

Presença em Sala de Aula • Evitem chegar atrasados • A aula iniciará as 13:00 • Presença será cobrada todos os dias, em todas as aulas, exceto: – vista e devolução de avaliações – substitutiva

Presença em sala de aula • Reprovações por faltas: mais de 25% de faltas

• Não existe abono de faltas!!! Ver normas acadêmicas: RESOLUÇÃO Nº 14/2015/CONEPE

– Art. 117. A presença do discente é registrada por sua frequência em cada hora-aula. • § 1º Não será permitido abono de faltas, ressalvados os casos previstos em lei.

Presença em Sala de Aula (Fonte: MEC) • “... Não existe legalmente abono de faltas. É admitida, para a aprovação, a freqüência mínima de 75% da freqüência total às aulas e demais atividades escolares” • “... a exigência mínima de 75% (sessenta e cinco por cento) de freqüência do total de horas letivas para aprovação dá ao aluno o direito de faltar às aulas até o limite de 25% (vinte e cinco por cento) do referido total.”

Como serão as notas? – P1: Prova individual, sem consulta – P2: Prova individual, sem consulta – P3: Prova individual, sem consulta – Cada avaliação vale de 0 a 10 – Nota final: (P1+P2+P3) / 3 – Uma substitutiva S substitui a menor nota.

Estudo durante a disciplina • Muito importante o estudo semanal e constante

• Ler os slides NÃO é suficiente • • • •

Participem das aulas Busquem aprender com os livros Façam os exercícios propostos Trabalhem no projeto

Bibliografia • 1. Básica:

• PRESSMAN, Roger S; FECCHIO, Mario Moro (Trad.). Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016. 950p. • SOMMERVILLE, Ian. Engenharia de software. 9.a Edição, 2012, Pearson. • BOOCH, JACOBSON, RUMBAUGH. UML – Guia do Usuário, 2.a edição. • BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML 2. 2. ed. rev. e atual. Rio de Janeiro: Elsevier; Campus, 2006. 496 p. • BEZERRA,EDUARDO. Princípio de Análise e Projetos de Sistemas com UML. Elsevier, Campus • CRAIG LARMAN. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall; 3 edition (2004)

• 2. Complementar:   • BRUEGGE, B e DUTOIT, A. Object-Oriented Software Engineering, Second Edition, Pearson. • PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo, SP: Prentice Hall, 2004. 535 p.

Introdução à Engenharia de Software

Definição de Engenharia • Engineering is about applying defined techniques, methods, processes, scientific and mathematical knowledge to the design, construction and implementation of artifacts such as buildings, bridges, planes, ships and machines (ABET, 1941).

O problema de desenvolvimento de software ... • Maurice Wilkes, one of the first men ever to program a modern, stored program digital computer, loved to recall in later life the “exact instant” in June 1949 when he “realized that a good part of the remainder of my life was going to be spent in finding errors in my own programs.”

O que é software? • Programas de computador, que quando executados proveem funcionalidades, juntamente com as estruturas de dados que possibilitam aos programas manipular corretamente a informação, e documentação associada, que descreve as formas de operar e usar os programas.

Diferenças entre hardware e software • Software é desenvolvido, não manufaturado no sentido clássico • O custo do software está no desenvolvimento, não na replicação • Software é abstrato e intangível

Definição de Engenharia de Software • Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Definição de Engenharia de Software • Disciplina de engenharia cujo foco está em todos os aspectos da produção de software, desde os estágios iniciais da especificação do sistema até sua manutenção, quando o sistema já está sendo usado.

Disciplina de engenharia • Há a aplicação de teorias, métodos, técnicas, processos, ferramentas • Há a mensuração dos processos e dos produtos • Processos levam a produção de produtos • Abordagens sistemáticas, bem definidas, repetíveis

Todos os aspectos da produção de software • Processos técnicos – Requisitos, implementação, testes, …

• Processos gerenciais/organizacionais – Gerenciamento do projeto, implantação do projeto no ambiente, aspectos sociais, …

Aplicações de Software • • • • • • • •

Automação industrial Business software Video games Telecommunications Internet Banco de Dados Software Educacional Software médico

• • • • • • • •

Editores de imagens Planilhas eletrônicas Software de simulação Editores de texto Software de Apoio a Decisão Compiladores Sistemas Operacionais Sistemas de Informação

Arte ou Engenharia? • Arte? Engenharia? • Arte e Engenharia?

Objetos de Estudo da Engenharia de Software • Diminuir o tempo da produção de software • Aumentar a qualidade, robustez e confiabilidade • Diminuir custos e prazos

Objetos de Estudo da Engenharia de Software • Melhorar as técnicas de estimativa e gerenciamento • Melhorar o processo de desenvolvimento • Automatizar o desenvolvimento com ferramentas

Dificuldades no desenvolvimento de software

Dificuldades no desenvolvimento de software • Dificuldade de manutenção • Requisitos mal definidos, errados • Falta de recursos humanos

Discussão • Apresentem outras dificuldades de desenvolvimento de software

Manutenção de Software • NASA's Space Shuttle program still uses a large amount of 1970s-era technology.

Por que manter software? • O SW deve ser adaptado para as novas necessidades de computação e tecnologia • O SW deve evoluir para implementar novos requisitos de negócio • O SW deve ser extendido para torná-lo interoperável com outros sistemas modernos, como bancos de dados e sistemas operacionais

Processos de Desenvolvimento de Software • Elicitação de Requisitos – Qual o problema? – O que será feito?

• Análise e projeto de software – Como será feito? – Descrição computacional – Projeto de arquitetura e detalhado

• Implementação • Testes • Implantação

Manutenção - quantidade de pessoal

Manutenção - quantidade de tempo

“The Maintenance Iceberg” • Vários estudos experimentais • 48% a 80% dos recursos de TI são gastos com manutenção.

“The Maintenance Iceberg” • “maintenance programmers may experience negative attitudes, such as lack of motivation, and persistent frustration over the possible unfavourable consequences of unsuccessful maintenance. ”

Breve histórico de hardware, software e aplicações

Breve histórico de hardware, software e aplicações

Computadores anos 1950 • UNIVAC 1101 (1950) • •

This computer was 12 m long, 6.1 m wide, weighed about 7.6 t and used 2700  vacuum tubes for its logic circuits. Its drum memory was 22 cm in diameter, had 200 read-write heads, and held 16,384 24-bit words (a memory size equivalent to 48 kB).

Computadores anos 1950 • The first business computer (1951), the Lyons Electronic Office (LEO) at Lyons Co.

Computadores anos 1950 • IBM 701 (1952) IBM’s first commercial scientific computer • 19 IBM 701 systems were installed. – 8 went to aircraft companies.

• The monthly rental for a 701 unit was approximately $8,100.

Computadores 1950s • Sep. 13, 1956, the IBM 305 RAMAC was the first computer to be shipped with a hard drive. •  5 million 6-bit characters (3.75 MB)  1 ton.

Computadores 1950s • IBM produces and markets the IBM 650. • Almost 2000 of these computers are sold in an eight-year span • Computador mais popular/importante da década de 1950. • 1,5 m X 0,9 m X 1,8 m e peso de 892 Kg • Em 1s: 1.300 somas e 100 multiplicações de números de dez dígitos.

Computadores 1960 • 1960 - IBM 1400 series machines, aimed at the business market. – 1.o computador a vender mais de 10.000 unidades – 50% de todos os computadores do mundo na época por volta da metade de 1960 – Alugado por U$ 2500 (U$21.000 atuais ) por mês

Computadores 1960 • The IBM 7030, also known as Stretch, IBM's first transistorized  supercomputer. • Fastest computer in the world from 1961 until 1964 • 1,2 MIPS • U$7,7milhões • 9 unidades vendidas

Família IBM 360 - 1964 • Família de modelos (20, 22, 25, 30, 40, 44, 50, 65, 67, 75, 85, 91, 95, 195) • 30 – 8kb a 64kb de RAM • 91 – 16MIPS – 256kb a 4MB de RAM • Produção até 1977

DEC - Digital Equipment Company's  • First successful minicomputer, the PDP-8 • Sold for $18,000 (U$140.000) • Over 50,000 are sold. • first commercially successful minicomputer

Control Data Corporation CDC 7600 - 1969 • Led by Seymour Cray, • Considered by most to be the first supercomputer. – 10MIPS – U$ 5M

IBM System/370 (S/370)  • 1970 a 1979 • Vários modelos, inicialmente com 64KB de RAM

IBM 4300 • 1979 a 1992 • 1979 – 4331, com 8MB de RAM • 1983 – 4381, com 64MB de RAM

IBM 390 • 1990 – 1999 • Primeiros modelos – 15MIPS – 66 MIPS – 128MB a 2GB de RAM

• Modelo de 1999 – 178MIPS a 1622 MIPS – 5GB a 32 GB de RAM

z/Architecture – 2000 em diante • Compatível com IBM 390 • IBM z800, z990, z890, System z9, System z10, zEnterprise 196, and zEnterprise 114. • Launched in July 2017 the z14 or just IBM Z is based on the z14 chip, a 10-core processor running at 5.2 GHz. • A z14 system can have a maximum of 240 Processing Unit (PU) cores and up to 32 TB RAM

Primeiros computadores no Brasil • • • • • • • • • • • •

Ano Empresa Equipamento 1960 PUC-RJ - IBM 1960 Jóquei Clube de São Paulo - IBM 1960 Anderson Clayton Ramac - IBM 305 1960 Esso Brasileira de Petróleo - IBM 1401 1960 IBGE – Instituto Brasileiro de Geografia UNIVAC - Remington 1961 Contadoria Geral de Transportes do Estado de São Paulo - IBM 1401 1961 General Electric do Brasil Ramac - IBM 305 1961 Volkswagen do Brasil Ramac - IBM 305 1962 Prefeitura de São Paulo - IBM 1401 1962 Ministério da Fazenda - IBM 1401 1962 Centro de Cálculo Numérico da USP - IBM 1620

Servidores atuais - blades

Software – Linguagens, padrões, frameworks • The first version of FORTRAN (formula translator) is published by IBM in 1954 • ALGOL 58 was first introduced in 1958. • COBOL first appeared in 1959 • ALGOL60 was released in 1960.

Software – Linguagens, padrões, frameworks • Joseph Weizenbaum of MIT wrote a program called Eliza that made the computer act as a psychotherapist in 1966. • Simula becomes the first programming language  to use inheritance in 1967 • AT&T Bell Laboratories developed Unix in 1969. • E. F. Codd at IBM formally introduces  relational algebra in 1970.

Software – Linguagens, padrões, frameworks • Niklaus Wirth invented the Pascal programming language in 1971. • Brian Kernighan and Dennis Ritchie  at Bell Labs invents C in 1972. • Vinton Cerf and Robert Kahn design TCP in 1973 • DES was approved as a federal standard in 1976. • Systems Network Architecture (SNA), IBM, 1974

Software – Linguagens, padrões, frameworks • Dan Bricklin creates VisiCalc in 1979 • WordStar was first released in 1978. • Bjarne Stroustrup, the programming language "C with classes" later renamed C++, in 1979. • IPv4 – 1981 • Microsoft Windows was announced on 1983. • Lotus 1-2-3, a spreadsheet was introduced 1983.

Software – Linguagens, padrões, frameworks • The ISO 9000 set of standards was first introduced in 1987. • Objective-C was licensed by NeXT in 1988. • On March 12, 1989, Tim Berners-Lee submitted a proposal for a distributed system at CERN, which would later become the WWW. • Guido Van Rossum began to develop Python in 1989.

Software – Linguagens, padrões, frameworks • The World Wide Web was launched to the public on August 6, 1991. • Linux was introduced by Linus Torvalds on August 25, 1991. • Microsoft released Visual Basic in May 1991. • Open Database Connectivity (ODBC) was developed by SQL Access Group. – 1992 • The NCSA released the Mosaic browser on April 22, 1993. • Netscape introduced SSL in February 1995. • On December 4, 1995, Sun announced JavaScript and Java.

Lei de Moore - 1965 • “ ... ever since the Integrated Circuit has been developed, the number of  transistors contained within them has doubled every two years. “

E o que temos hoje? • PC’s em empresas e casas

Mainframes

Desenvolvimento mainframe • Mainframes host critical core IT for: – 92 of the world’s top 100 banks; – 23 of the 25 top airlines; – 10 of the world’s top 10 insurers; – 71% of Fortune 500 companies.

Desenvolvimento mainframe • Mainframes run: – 30 billion transactions per day, – hold 80 % of the world’s business data, – handle 90 % of all credit card transactions.

Desenvolvimento mainframe • Mainframes host more transactions daily than Google – 1.3 million/second on CICS vs. 68,542/second on Google, – 55% of all enterprise transactions.

• Mainframes – consume only 6.2 % of worldwide IT spend. – run 68 % of production workloads

Mobile

Mobile OSs • Android (2007): 2,8% do mercado em 2009. – Atualmente: ~88%

• iOS (2007) – ~12%

• Windows Phone 10 e BlackBerry: irrelevantes

Embarcado • Telecommunications systems: – telephone switches, smartphones, ...

• Consumer devices: – MP3 players, – video game consoles, – digital cameras, – GPS receivers, – printers.

• Household appliances, – microwave ovens, – washing machines – dishwashers.

Embarcado • Transportation systems: – from flight to automobiles increasingly use embedded systems. – Automobiles, electric vehicles, and hybrid vehicles

• Embedded systems are used in – transportation, – fire safety, safety and security, – medical applications – life critical systems

Desenvolvimento de Software hoje • Enorme variedade de: – Linguagens e frameworks – Bancos de dados – Padrões – Métodos e processos – Ferramentas

Mas.... E os legados? • • • • • • • • •

Grandes varejistas Bancos Seguradoras Cartão de crédito Previdência Telecomunicações Governo Aviação Infraestruturas em geral

10 of the Oldest IT Systems in the Federal Government

• 1 • Agency: Treasury Department/Internal Revenue Service • System: Individual Master File • Reported age: Approximately 58 years old • What is it? The massive application that receives taxpayer data and dispenses refunds. “This investment is written in assembly language code and operates on an IBM mainframe,”.

10 of the Oldest IT Systems in the Federal Government

• 4 • Agency: Veterans Affairs Department • System: Personnel and Accounting Integrated Data • Reported age: 55 years old • What is it? An automated time-andattendance tracker. It runs on COBOL and on IBM mainframe computers.

10 of the Oldest IT Systems in the Federal Government

• 3 • Agency: Defense Department • System: Strategic Automated Command and Control System • Reported age: 55 years old • What is it? The system coordinates U.S. nuclear forces. It runs on 1970s-era IBM computer systems and uses 8-inch floppy disks. Each disk holds 80 kilobytes of data

• In a report released in 2016, congressional investigators found that about three-fourths of the $80 billion budget goes to keep aging technology running, and the increasing cost is shortchanging modernization.

Exemplos de linguagens com muitos legados • • • • • • • •

COBOL C/C++ Pascal Natural/ADABAS FORTRAN Delphi Visual Basic Java .... Java ? ? ? – Java foi lançado em 1995

Versões do Java • • • • • • • • • • •

JDK 1.0 (January 23, 1996) JDK 1.1 (February 19, 1997) J2SE 1.2 (December 8, 1998) J2SE 1.3 (May 8, 2000) J2SE 1.4 (February 6, 2002) J2SE 5.0 (September 30, 2004) Java SE 6 (December 11, 2006) Java SE 7 (July 28, 2011) Java SE 8 (March 18, 2014) Java SE 9 (September 21, 2017) Java SE 10 (March 20, 2018)

COBOL atualmente • COBOL supports close to 90% of Fortune 500 business systems today. • 70% of all critical business logic and information are written in COBOL. • COBOL – 65% of active code used today; – runs 85% of all business transactions.

• Between 60% and 80% of all transactions conducted worldwide are done in COBOL.

If it ain’t broke, don’t fix it.

Disponibilidade

Mercado de TI no Brasil • O mercado doméstico de TI (HW, SW e serviços) movimentou R$136 bilhões em 2017 (aprox. US$39 bilhões) • ~ 2,07 % do PIB – (Agricultura: ~ 3,5% do PIB)

• SW: US$8,2 bilhões (US$174M exportados) • HW: US$19,8 bilhões • Serviços: US$10,9 bilhões

Maiores produtos exportados • • • • • • • • • •

Soja triturada (US$ 13,3 bilhões e participação de 15%) Minério de ferro (US$ 8,69 bilhões e participação de 9,9%) Petróleo (US$ 7,23 bilhões e participação de 8,2%) Açúcar de cana (US$ 3,2 bilhões e participação de 3,7%) Automóveis (US$ 2,68 bilhões e participação de 3,0%) Carne de frango (US$ 2,6 bilhões e participação de 3,0%) Celulose (US$ 2,39 bilhões e participação de 2,7%) Farelo de soja (US$ 2,25 bilhões e participação de 2,6%) Café cru em grãos (US$ 1,99 bilhão e participação de 2,3%) Carne bovina (US$ 1,76 bilhão e participação de 2%). 

• Software: US$ 174M – participação de aprox. 0,2%

Empresas de Software • 5.138 empresas atuam no desenvolvimento e produção de software • Cerca de 95,5% podem ser classificadas como micro e pequenas empresas, até 99 funcionários. • Apenas ~ 230 tem mais de 100 funcionários.

Ver ABES 2018

Formação em TI por ano • Fonte: http://www.sbc.org.br/documentos-da-sbc/se nd/133-estatisticas/1200-pdf-png-educacao-s uperior-em-computacao-estatisticas-2017

Cursos de Computação no Brasil

Falhas de Software

• Ariane 5 Explosion • A data conversion from 64-bit floating point value to 16-bit signed integer • The rocket self-destructed 37 seconds after launch because of a malfunction in the control software • Ariane 4 software, written in Ada, was included in the Ariane 5

• Ver relatório em http://esamultimedia.esa.int/docs/esa-x1819eng.pdf

Falhas de Software • SOFTWARE HORROR STORIES:

http://www.cs.tau.ac.il/~nachumd/verify/horror.html

• History's Worst Software Bugs:

http://archive.wired.com/software/coolapps/news/2005/11/6 9355? currentPage=all

• Top 15 Worst Computer Software Blunders http://www.intertech.com/Blog/15-worstcomputer-software-blunders/

Falhas de Software • World War III Narrowly Averted http://www.washingtonpost.com/wp-srv/inatl/longter m/coldwar/shatter021099b.htm • Soviet Air Defence officer Stanislav Petrov may have saved the world on the night of September 26, 1983, when the Soviet nuclear early warning system malfunctioned and erroneously reported that the US had launched an attack on his country. Petrov later told the Washington Post that he “had a funny feeling in my gut” that the alarm was false, which was confirmed through further investigation.

Why Software Fails - Robert N. Charette

Complexidade do software • • • • • •

1993: Windows NT 3.1 - 6 million 1994: Windows NT 3.5 - 10 million 1996: Windows NT 4.0 - 16 million 2000: Windows 2000 - 29 million 2002: Windows XP - 45 million 2007: Windows Vista - ~50 million

• 2009: Windows 7 – 40 million • 2012: Windows 8: 65 million

Complexidade do software • Mozilla Firefox – Março 1998 – 1 MLOC – Março 2008 – 6,4 MLOC – Março 2018 - 36,8 MLOC

• Maria DB – Março de 2013 – 3,4MLOC – Março de 2018 – 4,6MLOC

https://www.openhub.net • Acessem o site

LOC - Google • Google’s total code base: – 2 billion lines of code. – 9 million source files – 86 terabytes of storage.

• To manage it all, Google created its own homegrown version control system called Piper • the company’s 25,000 developers commit 15,000 changes per day.

Veículos • 1981 – 50KLOC

• Atualmente: – Aproximadamente 100 MLOC – 70-100 microprocessadores – 1GB de software

• Crescimento de 30%-40% anual

“… the radio and navigation system in the current S-class Mercedes-Benz requires over 20 million lines of code alone and the car contains nearly as many ECUs as the new Airbus A380” • 80% da inovação em veículos são de responsabilidad e de software • Em alguns anos, 50% do custo do veículo será software

Como resolver? Testes? • Teste exaustivo é impossível • 100 LOCs com alguns caminhos e um único loop executando menos de 20 vezes gera 10 elevado a 14 caminhos de execução. • Testar todos os 100 trilhões de caminhos, assumindo que cada será avaliado em 1 milisegundo, levará 3170 anos

Outros exemplos de Sistemas Críticos • • • • • •

Controle de trens de alta velocidade Controle de tráfego aéreo Controle de usinas nucleares Controle de energia elétrica Sistemas de Telecomunicações Grandes Sistemas de Informação – Previdência – Saúde – Financeiro – Folhas de pagamento – Reservas de companhias aéreas – CRM – ERP

Surgimento da Engenharia de Software • Crise do software • Conferências NATO (1968 e 1969)

Google Data Center

Onde estão os Data Centers da Google?

Crise do software • The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. • — Edsger Dijkstra, The Humble Programmer (EWD340), Communications of the ACM

Crise do software • • • • • • • •

Projetos custando mais que o previsto Projetos demorando mais tempo que o previsto Software ineficiente Software de baixa qualidade Software não atingia todos os requisitos Projetos difíceis de gerenciar Código difícil de manter Software que nunca terminava

Conferências NATO • 1968 - The Conference was attended by more than fifty people, from eleven different countries, all concerned professionally with software, either as users, manufacturers, or teachers at universities. • 1969 - The conference was intended as a direct sequel to the NATO conference on software engineering held at Garmisch, Germany, from 7th to 11th October 1968. About sixty people from eleven countries attended the meeting.

NATO ? • The North Atlantic Treaty Organization or NATO (Organisation du traité de l'Atlantique Nord (OTAN)), also called the (North) Atlantic Alliance, is an intergovernmental military alliance based on the North Atlantic Treaty which was signed on 4 April 1949.

Discussão: Mitos do desenvolvimento de software • “Meu pessoal tem ferramentas de desenvolvimento de software que estão no estado da arte, afinal, compramos para eles os computadores mais novos”. • “Se nos atrasarmos no planejamento, podemos adicionar mais programadores” • “O estabelecimento geral de objetivos é suficiente para iniciar o desenvolvimento do software – podemos fornecer os detalhes posteriormente”

Discussão: Mitos do desenvolvimento de software • “Quando escrevemos um programa e o fazemos funcionar, nosso trabalho está completo” • “A engenharia de software nos fará criar documentação volumosa e desnecessária e irá atrasar a entrega do software“

Mais mitos?

Anuário Informática Hoje 2017 • • • • • • •

200 maiores empresas de TI do Brasil 1.a – Telefonica – R$17Bi 2.a – OI – R$11,7bi 3.a – CLARO – R$10,6 bi … 100.a – INMETRICS – R$103Mi ...

• 199 – PICTURE SOLUÇÕES EM TI – R$4,89Mi • 200 – DZYON – R$4,86Mi

Exercícios 1 – Explique a diferença entre projetos de software Green Field e Brown Field 2 – Explique por que na década de 1950 e início da década de 1960 existia a ideia de que devia-se projetar software da mesma forma do hardware.

Exercícios • 3 – Do ponto de vista da Engenharia de Software, faça um resumo das tendências das décadas de 1970, 1980 e 1990 relativas a linguagens de programação, processos e técnicas de desenvolvimento de software. • 4 - Por que houve uma explosão exponencial do número de programadores que trabalhavam com manutenção da década de 1980 para a década de 1990?

Exercício - Discussão • Procure informações sobre o downsizing em TI na década de 1990 no mundo. – O que teve de particular no downsizing em TI do Brasil em relação a outros países do mundo?

Exercício – Discutir o problema e apontar soluções • Suponha que vocês são diretores de tecnologia de uma empresa financeira. Existe um sistema de avaliação de crédito que vem sendo desenvolvido desde 1992. Várias alterações já foram feitas neste sistema, mas a última grande mudança foi feita em 2009. Nos últimos 5 anos, apenas manutenções adaptativas foram feitas. • Agora é necessária a atualização completa do sistema, inclusive migrando de plataforma cliente-servidor para web. Da equipe de 2009, que contava com 12 profissionais, somente um, que era analista júnior na época, e hoje é sênior, mas em outro projeto, ainda trabalha na empresa. Como você resolveria este problema?

Leitura • Sommerville. Cap 1 • Pfleeger. Cap. 1 • Pressman. Caps 1 e 2

Discussão • Artigo. Boehm, B. “A View of 20th and 21st Century Software Engineering.”

Princípios e Linguagens de Modelagem e Projeto de Software

• Conhecimento geral • Independente de – linguagens de programação, – técnicas, – banco de dados, – plataforma de desenvolvimento

Modelo • Modelo: abstração de algo com a finalidade de entendê-lo antes de construí-lo – Para desenvolver sistemas complexos, é necessário abstrair diversas visões do sistema

Por que modelar? • Testar algo antes de construir – simulação, – provas formais

• Comunicação com stakeholders • Gerenciamento da complexidade – Separação de partes a serem tratadas de cada vez

• Redução dos custos de desenvolvimento

Princípios de Projeto e Desenvolvimento de Software • Abstração • Dividir para Conquistar (divide and conquer) • Separação de interesses (separation of concerns) • Representar o problema e a solução em diferentes perspectivas • Lembrar que alguém irá manter o software.

Abstração • Ater-se aos aspectos mais relevantes, ao mesmo tempo em que ignora-se os menos importantes. • Ajuda a gerenciar a complexidade.

Princípios de modelagem de software • O objetivo principal da equipe de desenvolvimento é produzir software, não modelos – Criar modelos: • úteis, • que possam ser alterados

• Não tente construir modelos perfeitos – O esforço de melhora do modelo trará benefícios?

Princípios de projeto de software • Componentes devem ser fortemente coesos – Cada componente deve ter funcionalidade única

• Componentes devem ser fracamente acoplados – entre si – com o ambiente

• Maior acoplamento -> maior propagação de erros e gastos com manutenção

Coesão e Acoplamento • Coesão – Módulos executam uma única tarefa

• Acoplamento – Grau de interconexão entre módulos

Coesão e Acoplamento • Classes com alta coesão – capturam uma única abstração – São mais reutilizáveis

• Classes com baixa coesão – Apresentam 2 ou mais grupos de atributos – Maior complexidade – Baixo reuso

Separação de Interesses • Problemas complexos podem ser mais facilmente tratados se forem divididos • Cada parte refere-se a interesses diferentes • Não subestimar o esforço de integrar as partes

Modularidade • Software monolítico não pode ser entendido – Grande quantidade de caminhos de execução – Alta complexidade

• Não modularizar demais ... nem de menos (overmodularity e undermodularity) – Encontrar um balanceamento pode ser difícil

Refinamento • Refinamento top-down é o desenvolvimento baseado em refinar os graus de detalhe do software • Detalhes de baixo-nível são descobertos durante o processo de desenvolvimento

Refatoração • Técnica de reorganização que simplifica o projeto ou o código de um componente sem alterar sua funcionalidade ou comportamento • Altera a estrutura interna sem alterar o comportamento externo

O que é refatorar? • • • •

Eliminar redundâncias Melhorar algoritmos Melhorar as estruturas de dados Ver livro: Refactoring em http://refactoring.com/catalog/

Exemplos de refatoração

Dicionário de Dados – Esquema de Documentação

• • • • • •

= é composto de + Concatenação {}n repetição [ | | | ] escolha de alternativas () opcional Ex.: nome = [Sr.| Sra.|Srta.] + família + nome

UML • Evolução de outros métodos/linguagens • “A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de software de um sistema.”

UML • UML é... • uma linguagem visual. • independente de linguagem de programação. • independente de processo de desenvolvimento.

• UML não é... • uma linguagem programação • um processo de desenvolvimento.

• Os artefatos gráficos produzidos de um sistema OO são definidos por diagramas da UML.

Diagramas da UML

Diagrama de Casos de Uso

Casos de Uso • O modelo de casos de uso é uma representação das – funcionalidades externamente observáveis do sistema – e dos elementos externos ao sistema que interagem com o mesmo.

• Esse modelo representa, na UML, os requisitos funcionais do sistema.

Utilidade dos Casos de Uso • Equipe de clientes (validação) – aprovam o que o sistema deverá fazer – entendem o que o sistema deverá fazer

• Equipe de desenvolvedores – Podem seguir um desenvolvimento dirigido a casos de uso. – Projetar outros diagramas (classes e dinâmicos)

• Testadores: como base para casos de teste

Composição dos Casos de Uso • O modelo de casos de uso é composto de duas partes: – textual, – gráfica.

• O diagrama da UML utilizado na modelagem gráfica é o diagrama de casos de uso. – visão global e de alto nível do sistema.

Casos de Uso - Definição • Especificação de uma seqüência de interações entre um sistema e os agentes externos. – Define parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos deste sistema.

• Um caso de uso engloba um conjunto coerente de requisitos funcionais do sistema

Dimensões para descrições textuais • A UML não define como essa descrição textual deve ser construída. • Há várias dimensões independentes para a descrição textual de um caso de uso: – Formato (contínua, tabular, numerado) – Grau de detalhamento (sucinta ou expandida)

Ex. Descrição Contínua

Ex. Descrição Numerada

Ex. Descrição tabular

Atores • Elemento externo que interage com o sistema. • Casos de uso representam uma seqüência de interações entre o sistema e o ator. – no sentido de troca de informações entre eles.

• Normalmente um agente externo inicia a seqüência de interações com o sistema.

Categorias de Atores • cargos (Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc); • organizações (Empresa Fornecedora, Agência de Impostos, Administradora de Cartões, etc); • outros sistemas (Sistema de Cobrança, Sistema de Estoque de Produtos, etc). • equipamentos (Leitora de Código de Barras, Sensor, etc.)

Atores • Um ator corresponde a um papel representado em relação ao sistema. • O mesmo indivíduo pode ser – o Cliente que compra mercadorias e – o Vendedor que processa vendas.

• Um ator pode participar de muitos casos de uso.

Diagrama de Casos de Uso • Representa graficamente os atores, casos de uso e relacionamentos entre os elementos. • Ilustra em um nível alto de abstração: – elementos externos – funcionalidades do sistema.

Ex. Diagrama de Casos de Uso

Elementos dos Diagramas de Casos de Uso • Atores e Casos de uso • Relacionamentos entre esses elementos: – Comunicação – Inclusão – Extensão – Generalização

• Para cada um desses elementos: – uma notação gráfica – uma semântica específica.

Ator, caso de uso, comunicação

Inclusão (include)

Extensão (extend)

Generalização

Quando usar os relacionamentos • Include: o mesmo comportamento se repete em mais de um caso de uso • Extend: quando um comportamento eventual (opcional) de um caso de uso tiver de ser descrito. • Herança: no sentido de reuso de comportamentos semelhantes

Resumo da notação

Identificação dos elementos dos casos de uso • Atores e casos de uso são identificados a partir de informações coletadas no levantamento de requisitos. • Não há uma regra geral que indique quantos casos de uso e atores são necessários para descrever um sistema. – A quantidade depende da complexidade do sistema.

Identificação de atores • O analista deve identificar: – as áreas da empresa que serão afetadas ou utilizarão o sistema. – fontes de informações a serem processadas e os destinos das informações geradas pelo sistema.

Identificação de Atores • • • •

Que órgãos, empresas ou pessoas (cargos) irão utilizar o sistema? Que outros sistemas irão se comunicar com o sistema? Alguém deve ser informado de alguma ocorrência no sistema? Quem está interessado em um certo requisito funcional do sistema?

Identificação de Casos de Uso • Quais são as necessidades e objetivos de cada ator em relação ao sistema? • Que informações o sistema deve produzir? • O sistema deve realizar alguma ação que ocorre regularmente no tempo?

Documentação dos atores • Uma breve descrição para cada ator deve ser adicionada. • O nome de um ator deve lembrar o papel desempenhado pelo mesmo. • Exemplo – “Aluno: representa pessoas que fazem um curso dentro da universidade.”

Documentação dos casos de uso • A UML não define um padrão para descrição textual dos casos de uso de um sistema. • É necessário que a equipe de desenvolvimento padronize o seu estilo de descrição. • Algumas seções normalmente encontradas: – Sumário – Atores – Fluxo principal – Fluxos alternativos

Documentação dos casos de uso Nome Descrição Identificador Importância Sumário Ator Primário Atores Secundários Pré-condições Fluxo Principal Fluxos Alternativos Fluxos de Exceção Pós-condições Regras do Negócio Histórico Notas de Implementação

Documentação de casos de uso – boas práticas • Comece o nome do caso de uso com um verbo no infinitivo (para indicar um processo ou ação). • Não descrever como o sistema realiza internamente um passo de um caso de uso. • Tente dar nomes a casos de uso seguindo perspectiva do ator primário. • Ex.: Registrar Pedido, Abrir Ordem de Produção, Manter Referência, Alugar Filme, etc.

Documentação de casos de uso – boas práticas • Não se preocupar com a interface gráfica durante a escrita • Não se preocupar com detalhes técnicos, a serem preenchidos posteriormente • Manter a descrição de cada caso de uso no nível mais simples possível.

Exemplos de Escrita 1a - O administrador identifica-se. 1b - O administrador insere seu ID e senha. 1c - O administrador digita seu ID e senha. 2a - O sistema registra a venda. 2b - O sistema grava a venda no banco de dados usando o comando SQL insert into ... 2c – O sistema chama o módulo XYZ com parâmetros do tipo ponto flutuante A e B para …

Casos de uso no processo de desenvolvimento • Um grupo de casos é alocado a cada iteração. – Em cada iteração, o grupo de casos de uso é detalhado e desenvolvido.

• O processo continua até que todos os casos de uso tenham sido desenvolvidos e o sistema esteja completamente construído.

Requisitos de Software

Motivação

Engenharia de requisitos de software • Requisitos são as funções e restrições que estabelecem exatamente o que o software deve fazer. • O processo de descobrir, analisar, documentar, rastrear e verificar essas funções e restrições é chamado de Engenharia de Requisitos • Engenharia de Requisitos é uma parte fundamental do desenvolvimento de um software

Classificação de requisitos • Funcionais: declarações sobre – O que o software deve fazer (e o que não deve fazer) – Como o software deve reagir a entradas específicas.

• Não funcionais: restrições sobre as funções oferecidas pelo software • Domínio: – Refletem características de um domínio. – Podem ser funcionais ou não-funcionais.

Ex. Requisitos funcionais • O usuário deverá ser capaz de pesquisar todos os boletos não pagos nos últimos 30 dias. • O software fornecerá telas apropriadas para o usuário ler documentos do repositório de documentos • Cada pedido será alocado a um único identificador

Sobre os requisitos funcionais • Podem (e devem) ser escritos em diferentes níveis de abstração. • Deve-se evitar ambiguidades. – Ex. O que são “telas apropriadas” ?

• A especificação deve ser: – Completa: todas as funções requeridas devem estar definidas – Consistente: requisitos não podem ter definições contraditórias

Sobre requisitos não-funcionais • Não dizem respeito diretamente às funções do software • Estão relacionados a propriedades emergentes – Relativos a um conjunto do sistema, e não a partes dele • Ex. confiabilidade, desempenho, segurança

• Devem ser quantificados na especificação de requisitos – Somente assim podem ser testados

Requisitos não-funcionais - Exemplos 1a) O software deve gerar o boleto a ser pago de forma rápida. 1b) O software deve gerar o boleto a ser pago o mais rápido possível. 1c) O software deve gerar o boleto a ser pago instantaneamente.

Requisitos não-funcionais - Exemplos 1d) O software deve gerar o boleto em no máximo 5 segundos. 1e) O software deve gerar o boleto em no máximo 5 segundos em pelo menos 90% dos pedidos.

Requisitos não-funcionais - Exercício • Reescreva corretamente o seguinte requisito: • O sistema deve ser de fácil uso pelos médicos e deve ser organizado de forma que os erros sejam minimizados.

*ilities • Accessibility, Administrability, Understandability, Generality, Operability, Simplicity, Mobility, Nomadicity, Portability, Accuracy, Efficiency, Footprint, Responsiveness, Scalability, Schedulability, Timeliness, CPU utilization, Latency, Throughput, Concurrency, Flexibility, Changeability, Evolvability, Extensibility, Modifiability, Tailorability, Upgradeability, Expandability, Consistency, Adaptability, Composability, Interoperability, Openness, Integrability, Accountability, Completeness, Conciseness, Correctness, Testability, Traceability, Coherence, Analyzability, Modularity, Reusability, Configurability, Distributeability, Availability, Confidentiality, Integrity, Maintainability, Reliability, Safety, Security, Affordability, Serviceablility, …

Requisitos do domínio • São derivados do domínio, não de necessidades específicas dos stakeholders • Podem ser: – Novos requisitos funcionais – Estabelecer como cálculos específicos são feitos – Restrições dos requisitos funcionais

Requisitos do domínio • Encontrados em: – Leis – Padrões – Regulamentações

• Ex. – Fórmulas científicas – Formulários padronizados – Formato de termos técnicos

Documento de requisitos

SRS (Software Requirements Specification)

• Clientes – Verificam se os requisitos atendem suas necessidades – Especificam mudanças nos requisitos

• Gerentes – Planejam o pedido de proposta do sistema – Planejam o processo de desenvolvimento do sistema

• Desenvolvedores – Compreender que sistema será desenvolvido – Desenvolver testes do sistema (validação)

Padrão IEEE 830/1998 • 1 – Introdução – 1.1 propósito do documento – 1.2 escopo do produto – 1.3 definições, abreviações – 1.4 referências – 1.5 visão geral do restante do documento

• 2 – Descrição geral – 2.1 perspectiva do produto – 2.2 funções do produto – 2.3 características do usuário – 2.4 restrições gerais – 2.5 suposições e dependências

Padrão IEEE 830/1998 • 3 – Requisitos específicos (não há padrão neste tópico) – Requisitos funcionais – Requisitos não-funcionais – Requisitos de interface – Requisitos do domínio – Restrições em geral, propriedades, características

• 4 – Apêndice • 5 - Índice

Processos da Engenharia de Requisitos • A engenharia de requisitos envolve diversas atividades, como: – Estudo de viabilidade – Elicitação de requisitos – Documentação de requisitos – Manutenção de requisitos – Rastreabilidade de requisitos – Análise de requisitos – Validação de requisitos

Por que requisitos mudam? • Stakeholders desenvolvem melhor compreensão do que querem/precisam • As organizações mudam • Alterações de HW, SW, ambiente • Mudanças nas leis e regras governamentais • Surgem novas necessidades para o software

Stakeholders • • • • • •

Usuários Clientes Gerentes Desenvolvedores Líderes de projeto Stakeholders que trabalham juntos para definir os requisitos do sistema

Dificuldade de elicitar requisitos • Stakeholders frequentemente não sabem o que querem • Stakeholders apresentam visões muito gerais • Pedidos irrealistas

Dificuldade de elicitar requisitos • Não conhecimento do domínio • Diferentes formas de expressar as mesmas idéias • Fatores políticos e de negócios podem influenciar • Alterações pedidas nos requisitos

Dificuldade de elicitar requisitos • “O cliente nunca sabe o que quer” • “Não pedi porque é óbvio” • “Basta incluir dois campos a mais no formulário” • “Funcionava mais rápido na fase de testes”

Técnicas de elicitação de requisitos • • • •

Brainstorming Entrevistas Etnografia Estudo de sistemas legados

Entrevistas • Os desenvolvedores preparam perguntas a serem respondidas sobre o futuro sistema • Os stakeholders apresentam informações sobre as funções a serem implementadas • Perguntas podem ser abertas, fechadas, e de continuidade • O questionamento deve seguir uma sequência lógica

Perguntas abertas • Solicita-se ao entrevistado como funciona uma tarefa, ou como o sistema deve reagir, o que ele deve fazer, etc – “Como será o relatório de vendas?” – “Quais informações são necessárias para cadastrar um cliente?” – “Como será gerenciado o pedido de férias de funcionários?”

Perguntas fechadas • Perguntas mais objetivas – “quantos relatórios serão gerados por semana?” – “quantas pessoas deverão ter acesso ao sistema?” – “quantos acessos são esperados à base de dados?” – “quais pessoas podem usar o módulo gerencial?”

Condução da entrevista • Iniciar por uma pergunta aberta – Como funciona determinado procedimento – Peça para explicar algo do processo atual

• Fazer perguntas de seguimento para dar foco a entrevista • Fazer resumos/sumários constantemente

Condução da entrevista • • • •

Usar perguntas previamente preparadas Fazer perguntas, não interrogatórios Tomar notas/gravar a entrevista Transcrever as anotações logo ao terminar

Estudo de sistemas legados • Frequentemente novos sistemas são desenvolvidos para substituir sistemas antigos (legados) • Requisitos de um novo sistema podem ser descobertos ao analisar sistemas legados

Documentação de requisitos • Vários diferentes diagramas, notações, técnicas, métodos • Vamos usar linguagem natural: – “O sistema deve ...” – “Se o sistema receber a entrada X, ele deve responder com a saída Y” – “O usuário deve entrar com X” – “O sistema deve ser capaz de X” – “Quando o usuário entrar com X, o software deve responder Y”

Exercício • Descubra ambiguidades ou omissões no seguinte trecho de uma especificação de requisitos • Reescreva usando as técnicas explicadas anteriormente

• Um sistema automático de emissão de passagens vende passagens de trem. Os usuários escolhem seu destino e apresentam um cartão de crédito e um número de identificação pessoal. A passagem é emitida e o custo dessa passagem é incluído em sua conta do cartão de crédito. Quando o usuário pressiona o botão para iniciar, uma tela de menu com os possíveis destinos é ativada, juntamente com uma mensagem para que o usuário selecione um destino. Uma vez selecionado um destino, pede-se que os usuários insiram seu cartão de crédito. A validade do cartão é checada e o usuário, então, deve fornecer um número de identificação pessoal. Quando a transação de crédito é validada, a passagem é emitida.

Leitura • Sommerville – Cap. 4 • Pressman – Cap. 8

Diagrama de Classes

Objetivos • Prover respostas para as seguintes perguntas: – Quais objetos constituem o sistema em questão? – Como as classes do sistema estão relacionadas entre si? – Quais são as responsabilidades de cada classe?

Modelo de Classes de Análise (Análise do Domínio) • Representa termos do domínio do negócio. • Idéias, coisas, e conceitos no mundo real. • Descreve o problema representado pelo sistema a ser desenvolvido, sem considerar características da solução a ser utilizada.

Classes • Descreve objetos por meio de atributos e operações. – Atributos: informações que um objeto armazena. – Operações: ações que um objeto sabe realizar.

Exemplo

Atributos • Elementos alfanuméricos e primitivos • Possuem um tipo, como string, int, float, ... • Exs.: nome, telefone, datas

Questão • Endereço deve ser modelado como: – Atributo? – Classe?

Nota sobre modelagem de software • Frequentemente não há a solução errada. • Depende também do domínio da aplicação. • Há modelos – Mais adequados – Menos adequados

• Ex.: CPF é atributo ou classe?

Notação para associações • Relacionamentos que são formados entre objetos durante a execução do sistema.

Participação • Uma característica de uma associação que indica a necessidade (ou não) da existência desta associação entre objetos. • Participação pode ser obrigatória ou opcional. – Se o valor mínimo da multiplicidade de uma associação é igual a 1, a participação é obrigatória – Caso contrário, a participação é opcional.

Acessórios para associações • A UML define três recursos de notação para associações: – Nome da associação: significado semântico a mesma. – Direção de leitura: indica como a associação deve ser lida – Papel: representa um papel específico em uma associação.

Um problema … • Em um relacionamento entre pessoa e empresa, denominado emprego, onde ficam os seguintes atributos: – dataContratação? – Salário?

Ex. Classe associativa

• Por que salário e dataContratação estão como atributos de Emprego?

Classe associativa • Classe que está ligada a uma associação, em vez de estar ligada a outras classes. • Usada quando: – duas ou mais classes estão associadas, – é necessário manter informações sobre esta associação.

• Não necessariamente relacionamentos N:N

Classe Associativa • Classes Associativas podem ser substituídas por classes comuns.

Exemplo de associação ternária • As linhas de uma associação n-ária se interceptam em um losango nomeado. • Raros

Associações reflexivas • Ligações entre objetos que pertencem a mesma classe. – Não indica que um objeto se associa a ele próprio.

Agregações e Composições • Assimétricas: – se um objeto A é parte de um objeto B, o objeto B não pode ser parte do objeto A

• Um comportamento que se aplica a um todo automaticamente se aplica às suas partes.

Agregações e Composições • Se uma das perguntas a seguir for respondida com um sim, provavelmente há uma agregação onde X é todo e Y é parte. – X tem um ou mais Y? – Y é parte de X?

Exemplo

Agregações e composições - diferenças • Destruição de objetos – Na agregação, a destruição de um objeto todo não implica necessariamente na destruição do objeto parte.

• Pertinência – Na composição, os objetos parte pertencem a um único todo.

Agregação e Associação • Existe pouca diferença semântica entre agregação e associação. • Na prática, agregação é usada raramente.

Restrições sobre associações

Herança: Generalização e Especialização • subclasse X superclasse . • classe base X classe herdeira . • classe de especialização X classe de generalização .

Herança de associações • Não somente atributos e operações, mas também associações são herdadas pelas subclasses.

Exemplo de herança

Cuidado com herança! • Evitar usar herança quando – a superclasse não tem atributos e métodos próprios – As subclasses não tem propriedades que diferenciem umas das outras

Classes Abstratas • Usualmente, uma classe existe para gerar instâncias da mesma – classes concretas.

• No entanto, podem existir classes que não geram instâncias diretas. – classes abstratas.

Notação para classes abstratas • Na UML, uma classe abstrata pode ser representada com o seu nome em itálico.

Exercício - desafio • Como modelar em um diagrama de classes: – Um carro possui uma cor ?

Diagrama de Objetos • A UML define um segundo tipo de diagrama estrutural, o diagrama de objetos. • Representa uma “fotografia” do sistema em um certo momento. – exibe as ligações formadas entre objetos conforme estes interagem e os valores dos seus atributos.

Exemplo – Diagrama de Objetos

item1 : ItemPedido quantidade = 6 Pedido1 : Pedido Pedido dataItemPedido =Produto 13/ 09/ 2002 hora = 10:00am

item2 : ItemPedido quantidade = 20

item3 : ItemPedido quantidade = 1

produto20 : Produto nome = "Caderno M" descrição = "Caderno em espiral tamanho médio" preçoUnitário = 4,50 desconto = 15 produto12 : Produto nome = "Caneta ESF" descrição = "Caneta esferográfi ca 5mm" preçoUnitário = 1,20 desconto = 2 produto07 : Produto nome = "Esquadro" descrição = "Esquadro de acrílico 20 cm" preçoUnitário = 2,35 desconto = 10

Técnicas de Identificação de Objetos, Atributos e Métodos • Técnicas usadas para identificar classes: – Categorias de Conceitos – Análise Textual de Abbott (Abbot Textual Analysis) – Análise de Casos de Uso

• De uso não exclusivo

Categorias de Conceitos • Conceitos concretos: edifícios, carros, salas de aula. • Papéis desempenhados por seres humanos: professores, alunos, empregados, clientes. • Eventos, ou seja, ocorrências em uma data e em uma hora particulares: reuniões, pedidos, aterrissagens, aulas. • Lugares: áreas reservadas para pessoas ou coisas: escritórios, filiais, locais de pouso, salas de aula. • Organizações: coleções de pessoas ou de recursos: departamentos, projetos, campanhas, turmas. • Conceitos abstratos: princípios ou idéias não tangíveis: reservas, vendas, inscrições, boleto.

Análise Textual de Abbott • Identificar termos da narrativa de casos de uso e documento de requisitos que podem sugerir classes, atributos, operações. • Nomes (substantivos e adjetivos) são destacados. • Após isso, os sinônimos são removidos.

Análise Textual de Abbott (cont.) • Cada termo remanescente se encaixa em uma das situações a seguir: – O termo se torna uma classe; – O termo se torna um atributo; – O termo não tem relevância alguma com o SW.

Análise Textual de Abbott (cont.) • Identificação de operações e associações: destacar verbos no texto. – Verbos de ação (calcular, confirmar, cancelar, comprar, fechar, estimar, depositar, sacar) são operações em potencial. – Verbos com sentido de “ter” são potenciais agregações ou composições. – Verbos com sentido de “ser” são generalizações em potencial. – Demais verbos são associações em potencial.

Análise Textual de Abbott (cont.) • A técnica pode levar à identificação de diversas classes candidatas que não gerarão classes. • A análise do texto de um documento pode não identificar uma classe importante. • As variações lingüísticas e as formas de expressar uma mesma idéia são bastante numerosas. – Evitem sinônimos nos documentos técnicos

Análise de Casos de Uso • Técnica preconizada pelo RUP. • Casos de uso como ponto de partida. – A realização de um caso de uso é responsabilidade de um conjunto de objetos que devem colaborar para produzir o resultado daquele caso de uso.

Análise de Casos de Uso • Procedimento de aplicação: – Estudar a descrição textual de cada caso de uso para identificar classes candidatas. – Para cada caso de uso, o texto (fluxos principal, alternativos e de exceção, pós-condições e précondições) é analisado.

• Pode-se categorizar as classes.

Categorização • Objetos de entidade : – usualmente objetos do domínio do problema

• Objetos de fronteira: – atores interagem com esses objetos

• Objetos de controle: – intermediários entre objetos de fronteira e de entidade, definindo o comportamento de um caso de uso específico.

Objetos de Entidade • Representam conceitos do domínio do negócio. • Características – Armazenam informações persistentes. – Participam de vários casos de uso.

• Exemplo: – Um objeto Pedido participa dos casos de uso Realizar Pedido e Atualizar Estoque.

Objetos de Fronteira • Comunicação do sistema com os atores. – traduzem os eventos gerados por um ator em eventos relevantes ao sistema – responsáveis por apresentar os resultados de uma interação dos objetos. – Existem para que o sistema se comunique com o mundo exterior.

Objetos de Controle • São a “ponte de comunicação” entre objetos de fronteira e objetos de entidade. • Responsáveis por controlar a lógica de execução correspondente a casos de uso. • Agem como controladores dos outros objetos para a realização de um caso de uso.

Importância da Categorização • Princípio: cada objeto é especialista em realizar um de três tipos de tarefa: – comunicar com atores (fronteira), – manter as informações (entidade), – coordenar a realização de um caso de uso (controle).

Importância da Categorização • A importância está relacionada à capacidade de adaptação a eventuais mudanças. – Cada objeto tem atribuições específicas dentro do sistema  mudanças podem ser menos complexas e mais localizadas. – Ex. Mudança de interface / plataforma

• Objetos mais específicos e menores

Modelo de Análise no Processo Iterativo e Incremental (cont.) • As construções do modelo de casos de uso e do de classes são retroativas uma sobre a outra. – Novos casos de uso podem ser identificados – Pode-se identificar a necessidade de modificação de casos de uso preexistentes.

Modelo de Análise no Processo Iterativo e Incremental (cont.)

Classes de Projeto • O modelo de classes de projeto é resultante de refinamentos no modelo de classes de análise. – É construído em paralelo com o modelo de interações.

• O modelo de classes de projeto é usado para a implementação das classes.

Aspectos a considerar na fase de projeto

• Adição de novas classes ao modelo • Atributos, operações e de associações • Descrever refinamentos e conceitos relacionados à herança, classes abstratas, Interfaces, polimorfismo.

Especificação de classes de fronteira • Não atribuir a essas classes responsabilidades relativas à lógica do negócio. • Classes de fronteira devem apenas servir como: – Ponto de captação ou – Ponto de apresentação de informações.

Especificação de classes de fronteira (cont.) • Se o sistema tiver que ser implantado em outro ambiente, as modificações resultantes sobre seu funcionamento seriam mínimas. • Essa separação resulta em melhor coesão.

Especificação de classes de fronteira (cont.) • Durante a análise, considera-se que há uma única classe de fronteira para cada ator. • No projeto, algumas dessas classes podem resultar em várias outras.

Especificação de classes de entidade • A maioria das classes de entidade permanece na passagem da análise ao projeto. • Classes de entidade são as primeiras classes a serem identificadas, na análise de domínio.

Especificação de classes de controle • Normalmente associado a um caso de uso • O controle pode ser particionado em duas ou mais outras classes para controlar diversos aspectos da solução. • Evitar a criação de uma única classe com baixa coesão e alto acoplamento.

Especificação de classes de controle • Responsabilidades de controlador de caso de uso: – Coordenar a realização de casos de uso. – Servir como canal de comunicação entre objetos de fronteira e objetos de entidade. – Mapear ações do usuário para mensagens a serem enviadas a objetos de entidade. – Manipular exceções das classes de entidades.

Especificação de outras classes • Diversos outros aspectos demandam a identificação de novas classes durante o projeto. – Persistência de objetos – Distribuição e comunicação (RMI, CORBA, DCOM) – Autenticação/Autorização – Classes para testes (Test Driven Development) – Uso de bibliotecas, componentes e frameworks

• Conclusão: a tarefa de identificação de classes não termina na análise.

Sintaxe para atributos e métodos Cliente +obterNome() : String +definirNome(in umNome : String) +obterDataNascimento() : Data +definirDataNascimento(in umaData : Data) +obterTelefone() : String +definirTelefone(in umTelefone : String) +obterLimiteCrédito() : Moeda +definirLimiteCrédito(in umLimiteCrédito : float) +obterIdade() : int +obterQuantidadeClientes() : int +obterIdadeMédia() : float

Sublinhado: método/atributo estático / : atributo derivado

Visibilidade • Qualificadores de visibilidade aplicáveis a atributos também podem ser aplicados a operações. – + visibilidade pública – # visibilidade protegida – - visibilidade privativa

• O real significado depende da linguagem de programação em questão. • O conjunto das operações públicas de uma classe é chamado de interface

Tipos de Herança • Com relação à quantidade de superclasses que certa classe pode ter. – herança múltipla – herança simples

Práticas a serem evitadas • Uso excessivo/inadequado de agregação e composição. • Lógica de negócio na camada view. • Heranças inadequadas • Um único objeto de controle para todo o sistema/módulos

POJO - Plain and Old Java Object • Classes com – Atributos – Construtor default  – Getters – Setters

• Geralmente são as classes de entidade. • https://martinfowler.com/bliki/POJO.html

POJO - Exemplo public class Employee { String name; public String id; private double salary; public Employee(String name, String id, double salary) { this.name = name; this.id = id; this.salary = salary; } public String getName() { return name; } public String getId() { return id; } public Double getSalary() { return salary; } }

O Problema de Herança • Encapsulation and Inheritance in Object-Oriented Programmin g Languages , artigo de 1986! “… na maioria das linguagens a introdução da herança compromete seriamente os benefícios do encapsulamento …” • Vejam em: https://www.cs.tufts.edu/comp/150CBD/readin gs/snyder86encapsulation.pdf

O Problema de Herança • Why extends is evil https://www.javaworld.com/article/2073649/ why-extends-is-evil.html

O Problema de Herança • Viola o Encapsulamento • Forte Acoplamento • Hierarquias Complexas

Herança deve ser usada quando fizer sentido • Herança não deve ser demonizada, mas também não deve ser usada sem sentido. • Ex.: Gato é um Animal (ok)

Herança em excesso • Mudanças na classe pai podem afetar todas as classes filhas, mesmo quando isso não for intencional. – Hierarquias de classes tem milhares de LOC!

• O acoplamento é forte, classes tem muito conhecimento sobre outras.

Exemplo • A relação é-um será constante durante todo o tempo de vida da aplicação? • Um Funcionário é-uma Pessoa (mas não sempre) – Funcionário representa um papel que a Pessoa desempenha uma parte do tempo. – E se a Pessoa é tanto um Funcionário quanto um Supervisor?

Práticas a serem evitadas • Classes com baixa coesão

Práticas a serem evitadas

Exercícios • Para cada especificação a seguir, projete dois diagramas de classes: – De análise – De projeto

Convenções nesta disciplina • Classes de Análise – Métodos "simples“ com valor de retorno – Atributos com tipo e visibilidade – Associações nomeadas – Cardinalidades definidas – Classes de entidade

• Projeto – Métodos complexos (relativos a duas ou mais classes) – Métodos com atributos e valores de retorno – Atributos com tipo (inclusive criados) e visibilidade – Classes de fronteira e de controle (com métodos) – Projetado durante/após os modelos dinâmicos

• Um filme tem obrigatoriamente ao menos uma cópia, mas pode possuir diversas cópias. • Uma cópia refere-se exclusivamente a um determinado filme. • Um sócio pode realizar muitas locações enquanto permanecer sócio da locadora. • Uma locação refere-se unicamente a um determinado sócio. • Cada locação deve obrigatoriamente referenciar-se ao menos a uma cópia de um filme, podendo referenciar-se a muitas cópias. • Uma cópia pode ter sido locada diversas vezes. • Uma cópia não pode ser locada ao mesmo tempo por dois ou mais sócios.

“

Uma empresa de táxi possui 20 de carros. Nesta empresa trabalham 20 motoristas. Um motorista pode dirigir um carro no dia, e apenas um, mas pode dirigir vários carros enquanto for motorista da empresa. Um carro pode ser dirigido apenas por um motorista em um dia, mas pode ser dirigido por diversos motoristas enquanto o carro for de propriedade da empresa.”

  Dados do motorista: CPF, Nome, Telefone Dados do carro: Placa e Ano   CPF = XXX.XXX.XXX-XX, onde X = [0|1|2|3|4|5|6|7|8|9], Nome = [Sr.|Sra.|Srta] + Sobrenome + Pnome Sobrenome = {A-Z}^20 Pnome = {A-Z}^15 Telefone = codArea + tel, onde codArea = [0..9]^2 e tel = [0..9]^8 | [0..9]^9 Dados dos carros de luxo:   Placa = let + num Let = [A..Z]^3 Num = [0..9]^4   Ano = 2016 | 2017 | 2018

• Um cliente pode possuir muitos animais, mas um animal pertence a um único cliente. • A clínica precisa de informações a respeito de cada cliente, como nome, endereço, e telefone. • Um animal pertence a uma única espécie, e podem haver diversos animais cadastrados de uma determinada espécie. • É preciso manter informações a respeito de cada animal, como nome dado pelo cliente, sexo, idade e espécie. • Um animal pode realizar diversos tratamentos, mas um tratamento é realizado exclusivamente para um animal. • Cada tratamento possui ao menos uma consulta, mas pode possuir muitas consultas. • Uma determinada consulta refere-se exclusivamente a um determinado tratamento. • Para cada consulta devem ser armazenadas informações como a data em que foi realizada, o veterinário que atendeu o animal e o resumo da consulta. • Um veterinário pode realizar muitas consultas, porém uma consulta deve ser realizada por somente um veterinário. • Cada veterinário deve ser armazenado no sistema, com dados como especialidade, formação, e endereço. • Em uma consulta podem ser marcados exames para o animal, caso seja necessário.

• Uma universidade possui dois tipos de funcionários: professores e técnicoadministrativos. Quando são contratados, é necessário cadastrar o nome, telefone, endereço, CPF, e a data de contratação. • Para o professor deve ser cadastrado também a titulação, área de pesquisa, e o tipo de contrato (20 horas, 40 horas ou Dedicação exclusiva). • Um funcionário possui obrigatoriamente um único cargo. • Um cargo possui um título e um salário. • O salário do cargo pode ser aumentado apenas uma vez por ano. • Um professor pode não ministrar disciplinas em um semestre, ou ministrar até no máximo 3 disciplinas. • A disciplina pertence a um curso, ou a vários cursos. • Um curso possui muitas disciplinas. • Para o cadastro da disciplina, deve-se informar o nome da disciplina, a carga horária, e o tipo da disciplina. • Um curso pode ser de graduação ou de pós-graduação. O curso possui um nome, carga horária e uma área (ex. Exatas). • Cursos de pós-graduação podem ser de 2 tipos lato ou stricto sensu. • Cursos stricto senso devem ter a nota da CAPES e a grande área a qual pertencem.

• Um hotel possui 300 quartos, e precisa fazer um novo sistema para o controle de reservas, ocupação, e consumo. • O sistema deve armazenar reservas feitas por um funcionário de um ou mais quartos para um determinado cliente. • O sistema deve permitir que o funcionário verifique se um quarto está ocupado. • O sistema deve permitir que o funcionário insira os dados de um cliente. • O sistema deve permitir que o funcionário faça reservas de quartos para um cliente. • Cada cliente e funcionário devem ser cadastrados com os seguintes dados: nome, CPF, endereço e telefone. • O funcionário deve ser cadastrado com cargo, data de contratação e salário. • O sistema deve permitir o cadastro de quartos dos tipos simples ou luxo. Deve ser indicado o número de camas e o tipo de cada uma delas (solteiro ou casal, molas ou simples). • O sistema deve permitir que o quarto seja ocupado somente se estiver disponível. • Cada quarto deve ter apenas um frigobar, cujo conteúdo deve ser atualizado diariamente.

• Uma concessionária de veículos está querendo desenvolver um sistema de informação para controlar as atividades da oficina mecânica. As atividades a serem controladas são: • Controle de ordem de serviços • 1) Quando o cliente chega na concessionária, um atendente faz um resumo dos problemas encontrados no veículo e encaminha para um mecânico. O mecânico prepara um laudo inicial, contendo a especificação detalhada do problema, as peças a serem compradas (se for necessário), e o tempo estimado para realizar o serviço. • 2) De posse do laudo inicial, o atendente faz o cálculo do valor da ordem de serviço e informa ao cliente todos os detalhes do laudo inicial. Não é necessário que o cliente espere pelo resultado do laudo inicial. A informação pode ser dada por telefone ou email. • 3) O cliente precisa autorizar o serviço (seja por telefone ou por email) para que este seja iniciado. • 4) Um serviço pode ser feito por vários mecânicos, porém deve existir um único mecânico responsável. Apenas o responsável deve ser informado no laudo. • 5) Após o serviço, o mecânico responsável faz um laudo final, contendo tudo o que efetivamente foi feito. • 6) O laudo final deve conter além da descrição do serviço feito as peças trocadas (se existirem). • 7) O atendente e o mecânico são funcionários da concessionária.

• Controle de Veículos e Clientes • 1) O atendente é responsável por cadastrar e atualizar dados do veículo e do cliente. Para efeitos deste módulo do sistema, precisa-se das seguintes informações do cliente, do veículo e das peças: – Cliente: Nome, CPF, telefone, endereço – Veículo: Placa, marca, ano, fabricante – Peças: Nome, descrição, fabricante, preço

• Controle de Pagamento • 1) O cliente pode pagar em dinheiro ou cheque. • 2) Após o pagamento, o cliente recebe uma nota fiscal e o laudo de serviços final. • 3) A nota fiscal contém os dados do cliente, do pagamento, e do atendente.

• RF01 – O sistema deve permitir o cadastro de cursos contendo código, descrição, data de início e professor coordenador. • RF02 – O sistema deve permitir o cadastro de disciplinas de cursos, contendo código, descrição, carga horária, ementa, e bibliografia. • RF03 - Ao cadastrar uma disciplina, caso haja disciplinas que são pré-requisitos, o sistema deve permitir que sejam cadastradas as disciplinas que são pré-requisitos para cada disciplina. • RF04 – O sistema deve permitir o cadastro de alunos, contendo matrícula, email, nome, endereço (Logradouro, Numero, Bairro, Cidade, CEP), telefone e o curso para o qual foi aprovado. • RF05 – O sistema deve permitir o cadastro de professores, contendo nome, email, endereço (Logradouro, Numero, Bairro, Cidade, CEP), telefone, titulação máxima (especialização, ou mestrado, ou doutorado), e seu vínculo, ou seja, data de contratação e salário, além de curso ao qual este está alocado. • RF06 – O sistema deve permitir a abertura de turmas de disciplinas, informando ano e semestre, dias da semana e horários de realização. • RF07 – O sistema deve permitir a alocação de professores a determinadas turmas. • RF08 – O sistema deve permitir a emissão de diários de classe das turmas. • RF09 – O sistema deve permitir a emissão de históricos escolares dos alunos. • RF10 – O sistema deve permitir o controle da situação de um aluno, podendo estar matriculado, trancado, formado ou evadido.

Diagramas de Sequência e Comunicação

Introdução • Faltam informações aos modelos de Classes de Análise: – De que forma os objetos colaboram para que um determinado caso de uso seja realizado? – Em que ordem as mensagens são enviadas durante esta realização?

Objetivos da criação de modelos de interação • Obter informações adicionais para completar e aprimorar outros modelos – Quais os métodos de uma classe? – Quais os objetos participantes da realização de um caso de uso? – Uma classe precisa de mais atributos? – Uma classe precisa de mais métodos?

Mensagens • Diagramas de interação ajudam a Identificar mensagens

O que uma mensagem indica? • Uma mensagem implica na existência de uma operação no objeto receptor. • A resposta do objeto receptor ao recebimento de uma mensagem é a execução da operação correspondente.

Exemplos de mensagens • Mensagem simples, sem cláusula alguma. – 1: adicionarItem(item) • Mensagem com cláusula de condição. – 3 [a > b]: trocar(a, b) • Mensagem com cláusula de iteração e com limites indefinidos. – 2: *desenhar( ) • Mensagem com cláusula de iteração e com limites definidos. – 2 *[i := 1..10]: figuras[i].desenhar( ) • Mensagem aninhada com retorno armazenado na variável x. – 1.2.1: x := selecionar(e)

Diagramas de interação • O diagrama de seqüência e o diagrama de comunicação são equivalentes. • Diagrama de seqüência: – foco nas mensagens enviadas no decorrer do tempo.

• Diagrama de comunicação: – foco nas mensagens enviadas entre objetos que estão relacionados.

Diagrama de Sequência • Os objetos são organizados na horizontal. • Abaixo de cada objeto existe a linha de vida. – Cada linha de vida possui o seu foco de controle indicando que o objeto está fazendo algo.

Exemplo de diagrama de sequência

Mensagens reflexivas • Em uma mensagem reflexiva o remetente é também o receptor. – Corresponde a uma mensagem para this (self).

Criação/destruição de objetos

Quadros de interação • Elemento gráfico, que serve para modularizar a construção de diagramas de seqüência (ou de comunicação).

Exemplo

Diagramas referenciados

Alternativas

Iterações

Fragmentos de um diagrama de sequência

H

sequência • Primeira coluna: – o ator que iniciou o caso de uso.

• Segunda coluna: – um objeto de fronteira (usado pelo ator para iniciar o caso de uso).

• Terceira coluna: – o objeto de controle responsável pelo caso de uso.

Heurísticas para modelagem de diagramas de sequência • Objetos de entidade são acessíveis por objetos de controle. • Objetos de entidade nunca acessam objetos de fronteira ou de controle. • Objetos de entidade normalmente são compartilhados por outros diagramas de sequência.

Diagrama de comunicação • Chamado de diagrama de colaboração na UML 1.X. • Estruturalmente semelhante a um diagrama de objetos. – A diferença é que são adicionados setas e rótulos de mensagens nas ligações entre esses objetos.

• As ligações (linhas) entre objetos correspondem a relacionamentos existentes entre os objetos.

Diagrama de Comunicação • Os objetos estão distribuídos em duas dimensões – Vantagem: modelos mais legíveis comparativamente aos diagramas de seqüência. – Desvantagem: não há como saber a ordem de envio das mensagens a não ser pelas expressões de seqüência. • Direção de envio de mensagem é indicada por uma seta próxima ao rótulo da mensagem.

Elementos gráficos de um diagrama de comunicação

Exemplo de diagrama de comunicação

Exemplo de diagrama de comunicação

Criação de objetos em um diagrama de comunicação

Heurísticas para construção do MI • Verifique a consistência dos diagramas de interação: – em relação aos Casos de Uso – em relação ao modelo de classes.

• Cada cenário relevante para cada caso de uso foi considerado na modelagem de interações? • Durante a construção do diagrama de interação, pode-se identificar novas classes.

Heurísticas para construção do MI • Atributos, associações e operações podem surgir durante a construção dos diagramas de interação. • O objeto de controle realiza apenas a coordenação da realização do caso de uso. – Todas as ações do ator resultam em alguma atividade realizada por esse objeto de controle.

Heurísticas para construção do MI • Isso pode levar ao alto acoplamento; – No pior caso, o controlador tem conhecimento de todas as classes participantes do caso de uso.

• Sempre que for adequado, segundo os princípios de coesão e de acoplamento, as classes de domínio devem enviar mensagens entre si. –  alivia o objeto de controle

MI em um processo iterativo e incremental

Exercícios • Para cada especificação, desenvolva um diagrama de sequência e um de comunicação. • Use as classes entity, control e boundary nos diagramas

Locação de DVDs • Primeiramente o atendente deve verificar se o sócio está cadastrado. • Se o sócio não estiver cadastrado, a locação deve ser recusada. • Em seguida deve verificar se o sócio possui alguma locação pendente, caso em que também recusará o empréstimo. • Se o sócio existir e não tiver locações pendentes, então a locação deverá ser registrada. • Durante o registro da locação deverão ser registrados também todos os itens da locação • Após o registro as cópias são emprestadas ao sócio.

Clínica Veterinária (módulo de consulta)

• Se a consulta em questão não for a primeira consulta do tratamento, o veterinário antes de examinar o animal pode querer verificar o histórico das últimas consultas do tratamento. • Para isso será necessário consultar o cliente dono do animal que está sendo tratado. • A consulta ao cliente trará juntamente com as informações do cliente uma listagem de todos os animais por ele possuídos. • Por meio desta listagem, o veterinário selecionará o animal a ser tratado, obtendo informações específicas deste. • Após a consulta deve-se registrar seu histórico, contendo a data em que a consulta foi realizada, o resumo do que foi feito e o médico veterinário que realizou a consulta.

1 O paciente deseja registrar um pedido de consulta no hospital. 2 O atendente é o responsável pelo registro das consultas no sistema de informação hospitalar. 3 Primeiramente o paciente informa ao atendente seu número único (numu) ao atendente. 4 O atendente faz a pesquisa da ficha do paciente em seu cadastro no sistema por meio do numu, usando a tela do sistema. 5 A ficha contém os dados cadastrais do paciente. 6 O paciente então informa para qual especialidade ele quer a consulta, e qual a data da consulta. 7 Dada a especialidade, o atendente faz a busca no sistema de todos os médicos especialistas na área de interesse do paciente. 8 Com a listagem de todos os médicos pronta, o atendente informa ao paciente quais médicos estão disponíveis para a data que o paciente deseja (a listagem já informa a disponibilidade de cada médico). 9 O paciente escolhe um único médico. 10 O atendente registra a consulta.

Diagrama de Estados

Introdução • Cada objeto participante de um software se encontra em um estado particular. – Um objeto muda de estado quando acontece algum evento interno ou externo ao sistema.

• Quando um objeto transita de um estado para outro, o sistema também está mudando de estado.

Definição de Estado • Situação na vida de um objeto em que ele satisfaz a alguma condição ou realiza alguma atividade. • É função dos valores dos atributos e (ou) das ligações com outros objetos. Exs: – Atributo reservado deste objeto livro tem valor verdadeiro. – Conta bancária passa para o vermelho quando o seu saldo fica negativo. – Tanque está na reserva quando o nível está abaixo de 20%.

Estado Inicial e Final • O estado inicial indica o estado de um objeto quando ele é criado. • O estado final indica o fim do ciclo de vida de um objeto. • Normalmente verbos no gerúndio (esperando, cadastrando) ou representando uma condição (ligado)

Definição de evento • Ocorrência em um determinado momento do tempo – Usuário pressiona um botão – Carro é ligado – Ação é comprada

• Por definição, um evento é instantâneo

Definição de transição • Os estados estão associados a outros pelas transições. • Uma transição – indica mudança de estados. – é mostrada como uma linha conectando estados, com uma seta apontando para um dos estados.

• Quando uma transição entre estados ocorre, diz-se que a transição foi disparada.

Condição de guarda • Expressão de valor lógico que condiciona o disparo de uma transição. • A transição correspondente é disparada se e somente se o evento associado ocorre e a condição de guarda é verdadeira. • Transição que não possui condição de guarda é sempre disparada quando o evento ocorre.

Ação • Ao transitar de um estado para outro, um objeto pode realizar uma ou mais ações. • A ação associada a uma transição é executada se e somente se a transição for disparada.

Exemplo (Conta Bancária)

Exemplo (Oferta de turmas)

Na classe Turma ... Turma - qtdAlunos: int - capacidadeMaxima: int - lotada: bool Truma + cancelar(): void + fechar(): void + abrir(): void + +

Identificação de elementos no DTE • Cada operação com visibilidade pública de uma classe é um evento em potencial. • Identificação de eventos associados a transições: analisar as regras de negócio. – “Um cliente do banco não pode retirar mais de R$ 1.000 por dia de sua conta”. – “O número máximo de alunos por curso é igual a 30”.

Um DTE para cada classe • Os diagramas de estados são projetados por classe. • Desvantagens: – dificuldade na visualização do estado do sistema como um todo.

• Nem todas as classes de precisam de um DTE. – Classes que exibem comportamento dinâmico relevante. – Objetos cujo histórico precisa ser rastreado.

Modelagem de estados em um processo • Os DTEs são construídos com base nos diagramas de interação e nos diagramas de classes. • Durante a construção, novos atributos e operações podem surgir. – Essas novas propriedades devem ser adicionadas ao modelo de classes.

Exercício • Desenvolva um diagrama de estados para o módulo de locação de DVDs, com foco nos estados do objeto da classe Locação, de acordo com os outros modelos e os seguintes dados: • Deve-se verificar se não há locações pendentes. • Caso não haja pendências, deve-se iniciar o registro da nova locação, bem como de cada item locado. • Após selecionar todas as cópias desejadas para a locação, esta deve ser finalizada.

Diagrama de Atividades

Introdução • Tipo de fluxograma estendido • Permite representar ações concorrentes e sua sincronização.

Diagrama de Atividades • Pode-se especificar: – Processos de negócios – Comportamento interno de um objeto – Comportamento de casos de uso – Algoritmos

Elementos de diagrama de atividades • Elementos podem ser divididos em dois grupos: controle seqüencial e controle paralelo. • Elementos utilizados em fluxos sequenciais: – Ação – Atividade – Estados inicial e final, e condição de guarda – Transição de término – Pontos de ramificação e de união

• Elementos utilizados em fluxos paralelos: – Barra de bifurcação (fork) – Barra de junção (join)

Elementos

Fluxo de controle sequencial • Um estado em um diagrama de atividade pode ser: – estado atividade - leva um certo tempo para ser finalizado. – estado ação: realizado instantaneamente.

• Deve haver um estado inicial e podem haver vários estados finais e guardas associadas a transições.

Fluxo de controle sequencial • Ponto de ramificação possui uma única transição de entrada e várias transições de saída. – Para cada transição de saída, há uma condição de guarda associada.

Fluxo de controle paralelo • Uma barra de bifurcação recebe uma transição de entrada, e cria dois ou mais fluxos de controle paralelos. – cada fluxo é executado independentemente.

• Uma barra de junção recebe duas ou mais transições de entrada e une os fluxos de controle em um único fluxo. – A transição de saída da barra de junção somente é disparada quando todas as transições de entrada tiverem sido disparadas.

Diagrama de Atividades – formato geral

Swimlanes • Atividades de um processo podem ser distribuídas por vários agentes. – Ex. processos de negócio de uma organização.

• Isso pode ser representado usando swim lanes. • Cada compartimento contém atividades que são realizadas por uma entidade.

Exemplo de swimlanes

Modelagem da lógica de casos de uso • A realização de um caso de uso requer que alguma computação seja realizada. – “Passo P ocorre até que a C seja verdadeira” – “Se ocorre C, vai para o passo P”.

Modelagem da lógica de casos de uso • Os fluxos principal, alternativos e de exceção podem ser representados em um único diagrama de atividade.

Modelagem de Casos de Uso

Modelagem de Algoritmos • Nível de abstração mais baixo • Possibilidades de modularização

Ex. Modelagem de algoritmo

Exercícios • Faça um diagrama de atividades para representar o algoritmo para o cálculo do fatorial de um número.

Locação de DVDs • O sócio deve se dirigir ao atendente e apresentar seu código de registro. • O atendente pesquisará o sócio para verificar se este realmente se encontra registrado. • Se a pessoa em questão não estiver registrada, a locação deve ser recusada. • Caso o sócio esteja cadastrado, o sistema deve verificar se este possui alguma pendência, ou seja, se possui alguma locação ainda não devolvida. • Se houver alguma pendência a locação deverá ser recusada. • Se o sócio não possuir pendências, então o atendente irá registrar a locação, bem como cada uma das cópias locadas.

Projete um diagrama de atividades para um sistema de venda de passagens aéreas pela Internet, relativo ao módulo de compra de passagens por um cliente: - Primeiramente o cliente deve selecionar o local de origem, ou seja, um dos aeroportos da cidade onde o passageiro tomará o voo. - Em seguida, o cliente deve selecionar o local de destino, ou seja, o aeroporto da cidade para onde o passageiro deseja se dirigir. - Uma cidade deve ter ao menos um aeroporto, mas pode ter mais de um. - O cliente deve escolher uma data para o voo. - O sistema deve mostrar ao cliente a lista de voos com seus respectivos horários e valores. - Caso nenhum voo satisfaça o cliente, o processo deverá encerrado. - Caso o valor e o horário de algum voo satisfaça ao cliente, este poderá comprar passagens para o voo em questão, ou encerrar o procedimento. - Se decidir continuar, o cliente poderá comprar quantas passagens quiser, ou seja, o sistema deve permitir que ele compre qualquer número de passagens, enquanto existirem passagens a serem vendidas no voo em questão. - Em seguida deverá selecionar a forma de pagamento por meio da qual deseja pagar a passagem, e depois entrar com seus dados pessoais no formulário específico. - O cliente deve então pagar a(s) passagem(ns). - Somente após o pagamento efetuado a(s) passagem(ns) é (são) gerada(s) e o processo encerrado.

Mapeamento de Objetos para Tabelas Relacionais

SGBDR • Os SGBDR dominam o mercado comercial. – Oracle – MS-SQLServer – IBM DB2 – Informix – Sybase – Teradata – Ingres – MySQL – PostgreSQL – Outros...

Banco de Dados OO • Maiores informações: http://www.odbms.org/ • A informação a ser armazenada é o objeto • Apenas para nichos específicos – Telecomunicações – espaço – saúde – Multimedia – CAD/CAM/CAE

Tipos de objetos • Objetos podem ser persistentes ou transientes. • Objetos transientes: existem somente na memória principal. – Objetos de controle e objetos de fronteira.

• Objetos persistentes: têm uma existência que perdura durante várias execuções do sistema. – Tipicamente objetos de entidade.

Tarefas no Projeto de banco de dados • Construção do esquema do banco de dados • Armazenamento físico dos dados • Definição de visões sobre os dados armazenados. • Atribuição de direitos de acesso • Políticas de backup dos dados

Conceitos do modelo relacional - revisão • O modelo relacional é fundamentado no conceito de relação. • Cada coluna de uma relação pode conter apenas valores atômicos. • Chave primária: colunas cujos valores podem ser utilizados para identificar unicamente cada linha de uma relação.

Conceitos do modelo relacional revisão • Associações entre linhas: valores de uma coluna fazem referência a valores de uma outra coluna. (chave estrangeira) . – Uma chave estrangeira também pode conter valores nulos, representados por NULL.

• O NULL é normalmente usado para indicar que um valor não se aplica, é desconhecido, ou não existe.

Mapeamento de objetos para o modelo relacional • É a partir do modelo de classes que o mapeamento de objetos para o modelo relacional é realizado.

Mapeamento: Classes e seus atributos • Classes são mapeadas para tabelas. – Caso mais simples: mapear cada classe como uma tabela, e cada atributo como uma coluna. – No entanto, pode não haver correspondência unívoca entre classes e tabelas.

• Atributos, de forma geral, são mapeados para uma ou mais colunas. • Nem todos os atributos de uma classe são persistentes (atributos derivados).

Mapeamento de associações • O procedimento utiliza o conceito de chave estrangeira . • Há três casos, cada um correspondente a um tipo de conectividade. • Nos exemplos dados a seguir, considere o seguinte diagrama de classes:

Mapeamento de associações 1..1 • Raramente acontecem • Deve-se adicionar uma chave estrangeira em uma das duas tabelas.

Exemplo de mapeamento de associação 1..1

Mapeamento de associações muitos-muitos

• Uma tabela de associação deve ser criada. • Alternativas para definir a chave primária. – definir uma chave primária composta, combinando as chaves primárias das tabelas. – criar uma coluna de implementação que sirva como chave primária simples da relação de associação.

Mapeamento de agregações • Mesmo procedimento para realizar o mapeamento de associações. • A diferença semântica influi na forma como o SGBDR deve agir quando um registro da relação correspondente ao todo deve ser excluído ou atualizado. – Remoção ou atualização em cascata.

Mapeamento de associações n-árias • Associações n-árias (n ≥ 3): procedimento semelhante ao utilizado para associações binárias de conectividade muitos para muitos . – Uma relação para representar a associação é criada. – Se a associação n-ária possuir uma classe associativa, os atributos desta são mapeados como colunas da tabela de associação.

Mapeamento de classes associativas • Mapeamento é feito criando uma tabela para representá-la. • Os atributos da classe associativa são mapeados para colunas dessa tabela. • Essa tabela deve conter chaves estrangeiras que referenciem as tabelas correspondentes às classes que participam da associação.

Mapeamento de Herança Alternativas • Vertical: – cada classe é representada por uma tabela – usa-se uma chave estrangeira para combinar as subclasses com a superclasse.

• Horizontal: – Atributos da superclasse são "empurrados" para as subclasses – Elimina-se a superclasse

Mapeamento vertical

Mapeamento Horizontal

Mapeamento de herança • Mapeamento vertical: (uma relação para cada classe da hierarquia) – é a que melhor reflete o modelo OO. – Desvantagem: desempenho da manipulação das relações. • Inserções, remoções e junções.

Mapeamento de herança • Mapeamento Horizontal: – vantagem de agrupar os objetos de uma classe em uma única relação. – Todas as tabelas correspondentes a subclasses devem ser modificadas quando a definição da superclasse é modificada.

Uso de SGBDOO ou SGBDOR • Os principais SGBDR começaram a incorporar características de orientação a objetos. • Esses SGBD passaram a adotar o modelo de dados objeto-relacional, onde são adicionadas características da orientação a objetos. • Os principais SGBD são sistemas de gerência de bancos de dados objeto-relacionais (SGBDOR).

Arquitetura de Software

Primeira referência ao termo Arquitetura de Software

• NATO Conf. (1969), Ian Sharp - “I think that we have something in addition to software engineering: something that we have talked about in small ways but which should be brought out into the open and have attention focused on it. This is the subject of software architecture. Architecture is different from engineering.”

Pioneiros • Edsger Dijkstra – The Structure of "THE" - Multiprogramming System. Commun. ACM 11(5): 341-346 (1968)

• David Parnas – “A Technique for Software Module Specification with Examples”, Communications of the ACM, 15, (5), May 1972, pp. 330-336. – “On the Criteria to be Used in Decomposing Systems into Modules”, Communications of the ACM, 15, (12), 1972, pp. 1053-1058.

Definições Importantes • Um modelo é uma simplificação da realidade, criado para que o software seja melhor entendido; • Uma visão é uma representação do software a partir da perspectiva de um conjunto de concerns • Um stakeholder é um indivíduo, equipe ou organização com interesses em um software.

O que são concerns? • Um concern pode ser uma expectativa, uma necessidade, um objetivo, uma responsabilidade, uma restrição, uma dependência, um atributo de qualidade, riscos, … • Exs.: functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behavior, performance, resource utilization, reliability, security, information assurance, complexity, evolvability, openness, concurrency, autonomy, cost, schedule, quality of service, flexibility, agility, modifiability, modularity, control, inter-process communication, deadlock, state change, subsystem integration, data accessibility, privacy, compliance to regulation, assurance, business goals and strategies, customer experience, maintainability, affordability and disposability

Por que Arquitetura de Software? • Conceito provado na prática, no desenvolvimento de grandes sistemas de software • “As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems”. (David Garlan and Mary Shaw, 1994) • “A proven concept to build software-intensive systems and to avoid problems and failure causes, such as poor communication among stakeholders and sloppy and immature development practices, is to have a well-defined software architecture” (Bass et al., 2003). • “Without an architecture that is appropriate for the problem being solved the project will fail” (Clements et al., 2001)

Por que Arquitetura de Software? • “Having an architecture allows the development of systems that are better and more resilient to change when compared to systems developed without a clear architectural definition.” (Booch, 2007) • “Software architecture is also considered one of the most significant technical factors in ensuring project success” (Brown and McDermid, 2007). • “Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. Getting it right sets the stage for everything to come - the system's development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed” (Bass et al 2003).

Por que Arquitetura de Software? • “For nearly all systems, extra-functional properties (quality attributes or engineering goals) such as performance, reliability, security, or modifiability are as important as making sure that the software computes the correct answer” (Clements et al., 2001) • Software architecture is the one thing that separates a big ball of mud from a maintainable solution. It’s about making things manageable by reducing unnecessary complexity by organizing the code base in a way that it feels natural. In fact, the results may surprise you, because investing in your architecture can drastically reduce the time it takes to onboard new team members. Software architecture is important because even if you’re writing clean code, it doesn’t mean that your solution is maintainable. (Alexandre Brisebois, Microsoft)

Definições • http://www.sei.cmu.edu/architecture/start/community.cfm (mais de 100!) • “Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” (ANSI/IEEE, 2000) • Boehm et al., 1995 – “A collection of software and system components, connections, and constraints – A collection of system stakeholders' need statements – Principles that demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements”

Definições • Clements et al., 1997: “The software architecture of a system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them” • Kruchten 1995: “Software architecture deals with the design and implementation of the high-level structure of the software. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements of the system, as well as some other, non-functional requirements.” • Bass et al 2003: “An architecture is the result of a set of business and technical decisions”

Alguns conceitos • Every interesting software-intensive system has an architecture • O foco da arquitetura são decisões significativas de design de software. – Grande impacto no desempenho, confiabilidade, custo, e robustez do software

• A Arquitetura estabelece um contexto para design e implementação

Alguns Conceitos • Conceito provado: software desenvolvido baseado em uma arquitetura bem definida são mais baratos e rápidos, e possuem melhor qualidade • Captura early design decisions, que serão sentidas em fases seguintes. • Base para reúso • Arquitetura define relação e interação entre os principais componentes

Alguns Conceitos • Arquitetura omite conteúdo sobre os componentes • Arquitetura define os princípios que dão suporte aos componentes e a estrutura do software. • Arquitetura não é uma única estrutura – uma única estrutura não é a arquitetura • Arquitetura de software é algo extremamente complexo para ser descrito em uma única dimensão (visão)

Conceitos errados de arquitetura de software • Arquitetura é design • Minha tecnologia favorita é a arquitetura • Arquitetura é estrutura do software

Arquitetura é Design • Toda arquitetura é design, mas nem todo design é arquitetura • O foco da arquitetura são as decisões de design mais significativas, que terão impacto nos requisitos não funcionais do sistema

Minha tecnologia favorita é a arquitetura

• Uma tecnologia apenas implementa uma parte da arquitetura • Uma arquitetura nunca deve estar ligada a uma tecnologia específica

Arquitetura é estrutura • Uma arquitetura envolve estrutura, componentes, interfaces, comunicação • Mas a dinâmica (behavior) do sistema também faz parte da arquitetura

Importância da Arquitetura de Software • Communication among stakeholders. stakeholders can use as a basis for mutual understanding, negotiation, and communication • Early design decisions. earliest point at which design decisions governing the system to be built can be analyzed.

Importância da Arquitetura de Software • Sem uma arquitetura, é difícil entender grandes softwares de maneira suficiente para fazer as decisões influenciarem a qualidade e a usabilidade. • A arquitetura define restrições à implementação

Importância da Arquitetura de Software • • • •

Deciding when changes are essential determining which change paths have the least risk assessing the consequences of proposed changes, and arbitrating sequences and priorities for requested changes

• all require broad insight into relationships, performance, and behaviors of system software elements

Importância da Arquitetura de Software • Decidir como organizar equipes e alocar tarefas. • Arquitetura não é uma fase do desenvolvimento.

Onde fica a arquitetura no ciclo de vida de software?

Onde fica a arquitetura no ciclo de vida de software?

Atributos de Qualidade • A arquitetura de software deve ser projetada de forma a respeitar um conjunto de atributos de qualidade. • Exs.: Desempenho, Escalabilidade, Modificabilidade, Segurança, Disponibilidade, Portabilidade, Testabilidade • Tradeoffs

Frase no site do SEI • Quality systems come from quality architectures. Quality architectures must come from you.

Exemplo incorreto de atributo de qualidade • “A aplicação deve ser escalável” – Imprecisa – Conexões simultâneas? – Volume de dados?

Exemplo correto • “It must be possible to scale the deployment from an initial 100 geographically dispersed user desktops to 1,000 without an increase in effort/cost for installation and configuration.” – Preciso – Significativo – mas … não é testável na prática, a não ser por simulação

Desempenho • Métrica que mostra: – O tamanho de trabalho que uma aplicação deve executar em um período de tempo – Deadlines que devem ser respeitados para uma operação correta.

• Poucas aplicações são hard real-time – Atrasos catastróficos

Medidas de desempenho:

Throughput (capacidade, rendimento, tráfego)

• Quantidade de trabalho de uma aplicação em uma unidade de tempo – Transações por segundo – Mensagens por minuto

• Média vs. pico máximo – Considerar apenas a média leva a desastres

Medidas de desempenho: Response Time • Associado ao tempo que uma aplicação leva para responder a um estímulo • Todas as respostas vs. média – Ex.: 95% das respostas devem ocorrer em até 10 segundos, e nenhuma resposta deve ocorrer em mais de 15 segundos

Medidas de desempenho: Deadlines • 36 horas para processar a previsão do tempo do dia seguinte  • Exs.: processamento de folha de pagamento

Escalabilidade: • “How well a solution to some problem will work when the size of the problem increases.” • Request Load • Simultaneous Connections • Data Size

Medidas de Escalabilidade: Request Load (carga requerida) • 100 transações por segundo no pico • 1 transação por segundo na média • O que acontece se a taxa precisar ser multiplicada por 10? – 100 transações por segundo no pico – 10 transações por segundo na média • Na teoria, nenhum problema

Medidas de Escalabilidade: Request Load (carga requerida) • Scale up – + CPU – + memória – Funciona bem se a aplicação for multi-threaded

• Scale out – Distribuir a aplicação em mais máquinas – Funciona bem se há bom balanceamento (loadbalancing)

Medidas de Escalabilidade: Simultaneous Connections

• Número de clientes simultâneos • Acima do limite: – Baixo desempenho – Quedas de serviços – Negação de serviços

Medidas de Escalabilidade: Data Size

• Qual o tamanho de dados suportados pela aplicação? • Como a aplicação se comporta quando o tamanho dos dados cresce?

Modificabilidade • Modificações são um fato no ciclo de vida da aplicação • O quão fácil é modificar a aplicação em termos de: – Novos requisitos funcionais – Novos requisitos não-funcionais

• Quanto mais flexível for o projeto  menos dolorosa é a modificação

O que torna a modificabilidade mais fácil? • Mudanças em componentes fracamente acoplados • Mudanças em componentes altamente coesos • Mudanças difíceis indicam problemas na arquitetura

Requisitos de Segurança mais comuns • Authentication: Aplicações podem verificar a identidade de seus usuários e aplicações. • Authorization: Usuários autenticados têm acesso definido (ex.: read-only vs read/write). • Encryption: As mensagens enviadas são encriptadas.

Tecnologias de segurança • Transport Layer Security (TLS) – Versão atualizada do SSL

• Logins em sistemas operacionais e bancos de dados • Grants em banco de dados

Disponibilidade • Relacionado a confiabilidade de uma aplicação • Falhas levam a aplicação a ficarem indisponíveis • Componentes replicados – Alta disponibilidade – Degradação ocorre nas falhas

Disponibilidade

Portabilidade • Portability depends on: – the choices of software technology used to implement the application, – the characteristics of the platforms that it needs to execute on.

Testabilidade • Testability: How easy or difficult is an application to test? • The more complex a design, the more difficult it is to thoroughly test. • Writing less of your own code by incorporating pre-tested components reduces test effort.

Trade-offs • Uma arquitetura que favorece um atributo de qualidade, pode desfavorecer outro – Ex.: alto desempenho pode implicar configurações específicas de uma plataforma, diminuindo a portabilidade

• Não é possível maximizar todos os atributos • Priorizações, documentação das decisões

Atributos de Qualidade • A arquitetura de software deve ser projetada de forma a respeitar um conjunto de atributos de qualidade. • Exs.: Desempenho, Escalabilidade, Modificabilidade, Segurança, Disponibilidade, Portabilidade, Testabilidade • Tradeoffs

Frase no site do SEI • Quality systems come from quality architectures. Quality architectures must come from you.

Exemplo incorreto de atributo de qualidade • “A aplicação deve ser escalável” – Imprecisa – Conexões simultâneas? – Volume de dados?

Exemplo correto • “It must be possible to scale the deployment from an initial 100 geographically dispersed user desktops to 1,000 without an increase in effort/cost for installation and configuration.” – Preciso – Significativo – mas … não é testável na prática, a não ser por simulação

Desempenho • Métrica que mostra: – O tamanho de trabalho que uma aplicação deve executar em um período de tempo – Deadlines que devem ser respeitados para uma operação correta.

• Poucas aplicações são hard real-time – Atrasos catastróficos

Medidas de desempenho:

Throughput (capacidade, rendimento, tráfego)

• Quantidade de trabalho de uma aplicação em uma unidade de tempo – Transações por segundo – Mensagens por minuto

• Média vs. pico máximo – Considerar apenas a média leva a desastres

Medidas de desempenho: Response Time • Associado ao tempo que uma aplicação leva para responder a um estímulo • Todas as respostas vs. média – Ex.: 95% das respostas devem ocorrer em até 10 segundos, e nenhuma resposta deve ocorrer em mais de 15 segundos

Medidas de desempenho: Deadlines • 36 horas para processar a previsão do tempo do dia seguinte  • Exs.: processamento de folha de pagamento

Escalabilidade: • “How well a solution to some problem will work when the size of the problem increases.” • Request Load • Simultaneous Connections • Data Size

Medidas de Escalabilidade: Request Load (carga requerida) • 100 transações por segundo no pico • 1 transação por segundo na média • O que acontece se a taxa precisar ser multiplicada por 10? – 100 transações por segundo no pico – 10 transações por segundo na média • Na teoria, nenhum problema

Medidas de Escalabilidade: Request Load (carga requerida) • Scale up – + CPU – + memória – Funciona bem se a aplicação for multi-threaded

• Scale out – Distribuir a aplicação em mais máquinas – Funciona bem se há bom balanceamento (loadbalancing)

Medidas de Escalabilidade: Simultaneous Connections

• Número de clientes simultâneos • Acima do limite: – Baixo desempenho – Quedas de serviços – Negação de serviços

Medidas de Escalabilidade: Data Size

• Qual o tamanho de dados suportados pela aplicação? • Como a aplicação se comporta quando o tamanho dos dados cresce?

Modificabilidade • Modificações são um fato no ciclo de vida da aplicação • O quão fácil é modificar a aplicação em termos de: – Novos requisitos funcionais – Novos requisitos não-funcionais

• Quanto mais flexível for o projeto  menos dolorosa é a modificação

O que torna a modificabilidade mais fácil? • Mudanças em componentes fracamente acoplados • Mudanças em componentes altamente coesos • Mudanças difíceis indicam problemas na arquitetura

Requisitos de Segurança mais comuns • Authentication: Aplicações podem verificar a identidade de seus usuários e aplicações. • Authorization: Usuários autenticados têm acesso definido (ex.: read-only vs read/write). • Encryption: As mensagens enviadas são encriptadas.

Tecnologias de segurança • Transport Layer Security (TLS) – Versão atualizada do SSL

• Logins em sistemas operacionais e bancos de dados • Grants em banco de dados

Disponibilidade • Relacionado a confiabilidade de uma aplicação • Falhas levam a aplicação a ficarem indisponíveis • Componentes replicados – Alta disponibilidade – Degradação ocorre nas falhas

Disponibilidade

Portabilidade • Portability depends on: – the choices of software technology used to implement the application, – the characteristics of the platforms that it needs to execute on.

Testabilidade • Testability: How easy or difficult is an application to test? • The more complex a design, the more difficult it is to thoroughly test. • Writing less of your own code by incorporating pre-tested components reduces test effort.

Trade-offs • Uma arquitetura que favorece um atributo de qualidade, pode desfavorecer outro – Ex.: alto desempenho pode implicar configurações específicas de uma plataforma, diminuindo a portabilidade

• Não é possível maximizar todos os atributos • Priorizações, documentação das decisões

Padrões de Arquitetura

Padrões e Estilos • Há um debate em relação a se esses termos representam o mesmo conceito • Um estilo de arquitetura é uma coleção de decisões de arquitetura que: – São aplicadas em um determinado contexto – Restringe decisões de projeto da arquitetura que são específicas a um determinado software

• Um padrão de arquitetura é um conjunto de decisões de arquitetura que são aplicáveis em um problema de design recorrente.

Padrões e Estilos • Vamos usar os dois termos como sinônimos neste curso • Patterns and styles are essentially the same thing, but as a leading software architecture author told me recently, “the patterns people won”.

Níveis de Padrões • Padrões de Arquitetura – Padrões de alto nível, usados para especificar a estrutura fundamental de um sistema de software

• Padrões de Projeto – Padrões em médio nível usados para organizar as funcionalidades de subsistemas de forma independente

• Idiomas – Padrões em baixo nível, orientados a resolver problemas de implementação específicos, ou como implementar algo em uma linguagem de programação

Padrões são abstratos • Patterns are an abstract representation of an architecture, in the sense that they can be realized in multiple concrete forms • Ex. No padrão publish-subscribe sabemos: – características gerais (desacoplamentos, troca de mensagens), mas não sabemos: – Como as mensagens são trocadas, quais os protocolos

Layers • Def.: The layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction • Contexto: grandes sistemas que precisam ser decompostos.

Camadas (Layered) • Organização hierárquica • Cada camada provê serviço para a camada acima • Cada camada é cliente da camada abaixo • Um dos padrões mais conhecidos

Camadas (Layered) • Cada camada provê um conjunto de serviços coesos, e possui interface bem definida – Não há nenhum outra conexão/dependência entre as camadas

• Os componentes de uma camada implementam serviços em diferentes níveis de abstração

Boas propriedades de camadas • Projeto em diferentes níveis de abstração – Particionamento de um problema complexo

• Facilita evolução do SW – Mudanças são localizadas (camadas N, N-1 e N+1)

• Alto reuso – Diversas implementações de cada camada (desde que as interfaces sejam mantidas) • Ex.: FTP, telnet em cima de TCP/IP

Boas propriedades de camadas • Alta coesão • Relativo baixo acoplamento • Diversos níveis de abstração, de mais específicos (top levels), para níveis mais gerais (lower levels)

Boas propriedades de camadas • Detalhes são escondidos de acordo com a conveniência, aumentando separation of concerns • Camadas podem ser agrupadas/expandidas

Desvantagens de Camadas • Não são todos os sistemas que podem ser estruturados em camadas • Desempenho – A informação precisa passar em muitos níveis

• Debug – Operações são implementadas em uma série de calls

Quantas camadas? • Difícil acertar o nível de abstração • Poucas – pode ocorrer baixa coesão, mudanças podem não ser tão isoladas, camadas podem ser muito grandes, baixo reuso

• Muitas – necessidade de muita colaboração entre camadas, baixo desempenho

Quando usar camadas? • Com o objetivo de aumentar as possibilidades de alterações, manutenibilidade, reusabilidade • Quando o desempenho não é um fator primordial • Quando nenhum outro estilo parece ser correto para o problema

Variante: Relaxed Layers • Cada camada pode usar os serviços de todas as camadas acima. • Maior flexibilidade e desempenho • Menor manutenibilidade

Layers vs. Tiers • Layers: construções conceituais que separam logicamente funcionalidades de um sistema • Tiers: quando layers são implementadas em sistemas reais

One Tier-Architectures • Sistemas baseados em mainframes e terminais burros • Principal objetivo: uso eficiente de CPU • Sistemas monolíticos

Two-tier architectures

• Originados com o surgimento de PCs • Mainframes e grandes servidores conectados a PCs e workstations • A camada de apresentação é movida para o cliente – A capacidade computacional do cliente é aproveitada

• Arquitetura popular, particularmente como arquiteturas cliente-servidor

Three-tier architectures

• Como fazer o cliente conversar com vários servidores? • Como integrar diversos servidores? • Como aproveitar a largura de banda provida pelas redes? • Solução: 3-tier architectures

Three-tier architectures • A camada de aplicação pode ser distribuída entre diversos servidores, aumentando desempenho • A camada de aplicação é menos dependente de um determinado gerenciador de recursos, aumentando a portabilidade e o reuso

Three-tier architectures • A camada de gerenciamento de recursos precisa prover interfaces de forma uniforme (ex. ODBC, JDBC) – Desempenho é diminuído, mas há aumento de flexibilidade

N-tier Architectures (multi-tier)

• De forma genérica, n-tier architectures existem para: – Conectar sistemas diferentes – Adicionar sistemas à Internet

• A camada de gerenciamento de recursos pode incluir além de um banco de dados outros sistemas em camadas (2 ou 3) – ex. adicionar web servers na camada de apresentação

Existe o estilo em camadas? • In Stephen T. Albin's view in "The Art of Software Architecture: Design Methods and Techniques", hierarchical layer is not a real architecture style. He considers layer as the basic attribute of large complicated software architecture. In Stephen's view, all of the complicated systems have different layers, this means there exists a basic architecture structure view that represents system' s composition. So, Stephen did not describe the hierarchical layer in single part.

Pipe and Filters • Estilo que pode ser usado em sistemas que transformam strings de entrada em strings de saída • Não é útil para sistemas que interagem com pessoas ou para sistemas reativos • É muito usado quando grande string de dados deve ser processada

Pipe and Filters • Def.: The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems

Características • Filters lêem a entrada e produzem saída através de: – Refinamentos: comprimir ou extrair informações – Conversões: mudar o formato – Enriquecimento: adição de informações

• Filters – não possuem estados externos visíveis – Não comunicam com outros componentes

Vantagens • Filters podem ser facilmente modificados, substituídos • Filters podem ser rearranjados com pouco esforço (vários programas semelhantes podem ser desenvolvidos) • Filters são altamente reusáveis

Vantagens • Uso em grandes sistemas que devem tratar grande quantidade de dados • Filters podem ser combinados/divididos

Desvantagens • Filters geralmente consomem e produzem dados simples, como strings de caracteres • Tratamento de erros é difícil, tornando esse estilo inadequado quando segurança é um requisito • Componente mais lento em um pipeline • Inadequado para aplicações interativas

Compilador • O analisador léxico converte uma cadeia de caracteres em uma cadeia de tokens • O analisador semântico enriquece uma árvore sintática ao adicionar anotações a ela

Event-Driven • Boa escolha para – sistemas que devem reagir a eventos imprevisíveis do ambiente – softwares com complexa interface gráfica (o software deve estar pronto para vários eventos)

• Escalável • Efetivo para aplicações altamente distribuídas

Vantagens • Componentes que anunciam eventos não possuem conexão com componentes que respondem a eles (estão desconectados) • Relativamente fácil adicionar, remover e alterar componentes • A independência dos componentes dá suporte a reusabilidade, tolerância a falhas e robustness

Desvantagens • Componentes que anunciam eventos não podem garantir que algum componente irá responder • Não há garantia que a ordem de resposta é a ideal • O tráfego de eventos tem a tendência de ser altamente variável (possíveis problemas de desempenho)

Cliente-Servidor

• O cliente faz pedidos aos servidores e trata entradas e saídas do ambiente do sistema • O servidor oferece serviços. – Ex. File servers, print servers

• Vários usuários querem compartilhar e trocar dados.

Cliente-Servidor

• Os servidores possuem interfaces que descrevem os serviços que eles podem prover. • Os clientes iniciam as ações ao pedir serviços. – Portanto, o cliente deve saber a identidade do servidor para poder invocá-lo.

• Servidores não sabem a identidade nem o número de clientes antes do pedido de serviço.

Cliente-Servidor – análises a serem feitas • Funcionalidades – Determinar se os servidores são capazes de prover os serviços requeridos pelos clientes. – Determinar se os clientes usam os serviços de forma apropriada.

• Confiabilidade – Entender se um sistema consegue se recuperar após uma falha de um ou mais serviços.

Cliente-Servidor – análises a serem feitas • Análise de segurança: – determinar se a informação é limitada apenas aos clientes que têm o privilégio de recebê-la.

• Desempenho: – determinar se os servidores conseguem acompanhar os pedidos dos clientes, em termos de volume e taxas.

Cliente – servidor: Desvantagens • O cliente faz um pedido de serviço e espera até receber uma resposta. • O cliente precisa conhecer que tipo de serviço é oferecido por determinado servidor • O cliente precisa saber como contactar os servidores • Servidores podem atuar como clientes, fazendo pedido a outros servidores, mas não podem fazer pedidos aos clientes.

Centralizado • Um subsistema tem controle geral para iniciar e parar todos subsistemas • Tipos: – Call-return – Controlador

Microkernel • Def.: The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

Microkernel • Sistemas de software que devem ser capazes de se adaptar a mudanças nos requisitos. • Uma parte funcional mínima de funcionalidades é separada de partes específicas do cliente. • O microkernel também serve como socket para plugar as extensões • Geralmente associado a sistemas operacionais. – Outros domínios, como financeiro.

Problema • Desenvolver software para um domínio que precisa lidar com muitos padrões e tecnologias similares não é uma tarefa trivial. – Ex. SO e GUI.

• Fatores adicionais a considerar : – A aplicação deve lidar com mudanças de HW e SW

Solução com microkernel • Encapsular os serviços fundamentais da aplicação em um componente (microkernel) • O microkernel inclui funcionalidade que: – Mantém recursos do sistema (arquivos e processos) – Provê interfaces que permitem outros componentes acessar sua funcionalidade

Solução com microkernel • Funcionalidades devem ser separadas em servidores internos – Manter complexidade e tamanho

• Servidores externos são processos separados que representam uma aplicação.

Exemplos de microkernel • O kernel provê 4 serviços básicos: – Gerenciamento de processos e threads, – Low-level-management da memória do sistema, – Comunicação, tanto ponto-a-ponto, como em grupos – low-level I/O services.

• Serviços não providos pelo kernel devem ser implementados por servidores. – Desta forma, o kernel é pequeno e a flexibilidade é alta.

Benefícios • Portabilidade – Migrar o microkernel para um novo HW  modificações apenas em partes dependentes do HW

• Flexibilidade e Extensibilidade – adicionar um novo servidor externo – novas funcionalidades são implementadas adicionando-se servidores internos

• Alta manutenibilidade e modificabilidade

Distributed Microkernel • Uma variante do microkernel com benefícios: – Escalabilidade – Confiabilidade, por meio de availability e fault tolerance.

• Servidores executam em mais de uma máquina – Falhas não necessariamente impactam a aplicação – Falhas podem ser escondidas do usuário

• Transparência – Cada componente pode acessar outros componentes sem precisar saber sua localização.

Middleware • Gerencia as interações entre aplicações em plataformas heterogêneas • Integra coleção de servidores e aplicações sob uma interface comum • Middleware é similar à camada intermediária da arquitetura three-tier, com a diferença de estar distribuído entre múltiplas aplicações

Objetivos do Middleware • facilitar o desenvolvimento de aplicações distribuídas • facilitar a integração de sistemas legados

Características de Middleware • Abstrações que escondem a complexidade de construção de sistemas distribuídos • As abstrações estão no topo de uma complexa estrutura de software • Tipos: – RPC, Monitors, Brokers, Message-oriented

Remote Procedure Call • Proposto formalmente em 1984 • Idéia: chamada de procedimentos em outras máquinas de forma transparente • Cliente: – chama um procedimento remoto e espera o retorno

• Servidor: – programa que implementa o procedimento chamado

RPC - Problemas • RPC funciona bem enquanto clientes e servidores estão funcionando bem • Alguns problemas: – O cliente não consegue localizar o servidor – O pedido do cliente para o servidor é perdido – A resposta do servidor para o cliente é perdida – O servidor crashes após receber o pedido – O cliente crashes após enviar o pedido

Transaction Processing Monitors • Uma das formas mais antigas de middleware • IBM CICS (end of 1960's) • Desenvolvidos para que mainframes suportassem a distribuição de recursos • Portanto, precisavam de consistência de dados → transações

TP Monitors - Aplicações • Atualmente fazem parte de muitas aplicações: – Financeiras – Indústria de vendas de passagens – Seguradoras – Sistemas de controle industriais – 90% das Fortune 500 usam CICS

Monitores e Transações • Monitores suportam milhares de clientes de forma concorrente • Para isso usam threads ao invés de processos • Segundo a IBM, implementações de CICS atuais suportam 300 bilhões de transações diariamente

Object Brokers • Evolução natural de RPC • Differença: clientes chamam métodos de objetos • O broker é responsável por – Coordenar a comunicação – Transmitir resultados e exceções

• Usado em sistemas distribuídos heterogêneos com componentes independentes

Message-oriented middleware • Message-oriented middleware: fracamente acoplado (loosely-coupled), tecnologia assíncrona – unlike synchronous middleware such as CORBA.

• Infraestrutura de mensagens desacopla senders e receivers – Uso de uma fila de mensagens

• The sender can send a message to a receiver and know that it will be eventually delivered, even if the network is down or the receiver is not available.

Vantagens • O sender não precisa de uma resposta a uma mensagem. Ele envia a mensagem e continua seu processo – Send-and-forget messaging.

• O receiver pode demorar alguns minutos para ter uma resposta – Enquanto isso o sender pode continuar o trabalho.

• O sender confia no middleware para enviar a mensagem caso a conexão se perca

Desvantagens • MOM é uma tecnologia one-to-one. • Um sender envia uma mensagem para uma fila, e um receiver recebe a mensagem • Vários problemas não podem ser resolvidos por um estilo 1-1

Publish-subscribe • Estende mecanismos MOM básicos para suportar estilos de comunicação 1-n, n-1 e n-n • Senders e receivers são desacoplados • Subscribers podem dinamicamente subscribe e unsubscribe. • High-level of abstraction by hiding the complexity of a variety of platforms, networks and low-level process communication.

Características • Naturally supports an asynchronous, many-tomany communication between components in a network. • Event based communication between components – may act as publishers of information and/or subscribers for information.

Características • Publishers publish information through an event, which will be delivered to all (and only) interested subscribers, which expressed their interest in a certain type of information by subscribing to it. – This allows improved system performance.

Características • Publishers não sabem qual subscriber irá receber a informação publicada. • Subscribers são indiferentes em relação a qual publisher produz a informação. – Não precisam serem executados na mesma máquina (space-decoupled)

Características • Publishers e subscribers estão decoupled in time: – publishers e subscribers não precisam estar conectados ao mesmo tempo.

• All this manners of decoupling (synchronization, space and time decoupling) increases scalability and reduces the necessity of coordination, making publish-subscribe middlewares most suited to DRTS.

Referências • Caps. 1 e 2 do livro “Web Services – Concepts, Architectures and Applications”. Gustavo Alonso et al. Springer. • Patterns Oriented software architecture: A System of Patterns. Capítulo 2 • An Introduction to Software Architecture, David Garlan and Mary Shaw - January 1994 CMU-CS-94-166

Arquitetura 4+1

Definições – IEEE 1471/ISO/IEC 42010:2007

• Visão: – representação de um software (ou parte) a partir de uma perspectiva particular. – coleção de modelos representando a arquitetura do software.

Logical View • Relativo principalmente aos requisitos funcionais (o que o software deve fazer). • Identificação dos principais pacotes, subsistemas e classes • Diagramas mais comuns: – UML Class, Package and Sequence diagrams. – ER diagrams

Process View • Um processo é um grupo de tarefas. • A comunicação entre tarefas ocorre de várias formas: síncrona, assíncrona, broadcast, ... • Principais tópicos: – concorrência e distribuição, – integridade do software, – tolerância a falhas, – Como abstrações da visão lógica operam na visão de processos da arquitetura.

Process View • Principais estilos: client/server, pipes and filters, publish-subscribe middleware. • Essa visão mostra onde e como classes/elementos definidos na visão lógica são usados. • Notações usadas: Diagramas de Sequência e de Atividades, Diagrama de Classes (foco em classes ativas), Componentes

Implementation/Development view • Organização de módulos do software (arquivos, código, componentes, executáveis, bibliotecas,...) • Principais elementos: módulos, subsistemas, camadas. • Considera requisitos como: facilidade de desenvolvimento, restrições do ambiente e das linguagens de programação.

Implementation/Development view • A visão de desenvolvimento é a base para: – alocação de requisitos e de trabalho entre equipes – Avaliação de custos – Monitoração do projeto – Reuso, portabilidade e segurança.

Physical/Deployment View • Elementos identificados: redes, processadores, tarefas, objetos, mapeados em vários nós. • Configurações físicas diferentes podem ser usadas: – desenvolvimento, – testes, – Homologação, – implantação do software em diferentes locais/clientes.

Physical/Deployment View • Mostra como os executáveis e componentes são mapeados para plataformas e nós físicos • Mostra distribuição física de elementos do sistema • Notações: proprietária, pacotes, nós, UML deployment diagram

Scenario/Use Case View • Mostra como os elementos das 4 visões trabalham juntos. • Notações: – Use Cases – Linguagem natural – Pode-se especificar os use-cases com diagramas UML (Sequência, Atividades)

Scenario/Use Case View • Principais objetivos: – Direção para descobrir os elementos da arquitetura – Validação e ilustração da arquitetura do software – Ponto de partida para desenvolvimento e testes

Quantas visões? • Nem todo software precisa de – todas as 5 visões – várias visões

• Ex. – Um único processador → não precisa da visão de deployment – Um único processo → não precisa da visão de processos .

Siemens • Diferentes estruturas são usadas em diferentes fases do processo de desenvolvimento. – A arquitetura conceitual descreve o sistema em termos dos principais elementos de design e suas relações – A arquitetura de interconexão de módulos é composta por duas estruturas ortogonais: decomposição funcional e camadas. – A arquitetura de execução descreve a estrutura dinâmica de um sistema. – A arquitetura de código descreve as bibliotecas e o código fonte organizados no ambiente de desenvolvimento.

Leitura • Architectural Blueprints—The “4+1” View Model of Software Architecture

ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description

Escopo • Especifica como as descrições arquiteturais dos sistemas são organizadas e expressas. • Especifica visões, frameworks, e linguagens da aquitetura para uso em descrições arquiteturais. • Apresenta termos e conceitos; • Apresenta guia para especificar visões da arquitetura

Termos e definições • Architecting: processo de conceber, definir, expressar, documentar, comunicar, manter e melhorar uma arquitetura durante o ciclo de vida do sistema. • Architecture: conceitos ou propriedades fundamentais de um sistema em seu ambiente englobando seus elementos, relacionamentos, e os princípios do seu projeto e evolução.

Termos e definições • stakeholder : indivíduo, equipe ou organização interessados em um sistema.

Arquitetura no ciclo de vida • Pode-se arquitetar – Sistemas – Organizações

• Arquitetura refere-se a todo o ciclo de vida – Logo, influencia processos de várias etapas

Contexto da descrição arquitetural

O que são concerns? • Um concern pode ser uma expectativa, uma necessidade, um objetivo, uma responsabilidade, uma restrição, uma dependência, um atributo de qualidade, riscos, … • Exs.: functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behavior, performance, resource utilization, reliability, security, information assurance, complexity, evolvability, openness, concurrency, autonomy, cost, schedule, quality of service, flexibility, agility, modifiability, modularity, control, inter-process communication, deadlock, state change, subsystem integration, data accessibility, privacy, compliance to regulation, assurance, business goals and strategies, customer experience, maintainability, affordability and disposability

Contexto da descrição arquitetural Stakeholders e Concerns

• Stakeholders de um sistema têm concerns relacionados a um sistema e sua relação com o ambiente. • Um concern pode ser de interesse para vários stakeholders. • Concerns surgem no ciclo de vida, durante a especificação de requisitos, e a partir de escolhas de design.

Separation of Concerns (Dijkstra, 1974) • Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by “focussing one’s attention upon some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

Visões Arquiteturais • Uma descrição arquitetural inclui uma ou mais visões arquiteturais. • Uma visão está relacionada a um ou mais concerns – Ex.: visão de implementação está relacionada com subsistemas, modularidade, desempenho, complexidade

Decisões arquiteturais e rationale (razão fundamental) • Architecture rationale: mantém explicações, justificativas ou o raciocínio sobre as decisões arquiteturais tomadas. • Pode incluir: – Base para a decisão – Alternativas pensadas – Tradeoffs analisados – Consequências potenciais – Fontes de informações adicionais

AD element: qualquer elemento da arquitetura (stakeholder, decisão, modelos, visão, razão, …)

Architecture Description Languages • Uma (ADL) é qualquer forma de expressão para uso em descrições arquiteturais. • Exs.: Darwin, Rapide, C2, Wright, SysML , ArchiMate, …

Architecture frameworks • Architecture framework: estabelece uma prática comum para criar, interpretar, analisar e usar descrições arquiteturais em um domínio de aplicação ou comunidade – Exs.: Zachman’s, UK Ministry of Defence Architecture Framework, The Open Group’s Architecture Framework (TOGAF), Kruchten’s “4+1” view model, Siemens’ 4 views method, Reference Model for Open Distributed Processing (RM-ODP), ...

Como as descrições arquiteturais são usadas pelos stakeholders no ciclo de vida? • Como base para atividades de projeto e desenvolvimento • Como base para analisar e avaliar alternativas de implementação de uma arquitetura • Base para uma linha de produtos. • Comunicação entre partes envolvidas no sistema • Base para documentos de aquisição

Como as descrições arquiteturais são usadas pelos stakeholders no ciclo de vida? • Documentando as características do sistema para clientes, operadores, compradores, integradores, … • Planejamento de transição do sistema • Suporte para atividades de gerência, como planejamento, cronogramação e custos • Base para analisar e avaliar alternativas arquiteturais • Compartilhamento de lições aprendidas • Treinamento de stakeholders.

O que são decisões importantes (key decisions?) • Relativas a Requisitos significativos • Precisam de grande investimento de tempo/esforço para implementar • Afetam key stakeholders ou grande número de stakeholders • Não óbvias • Altamente sensíveis a mudanças • Base para planejamento e gerenciamento de projetos

Como documentar decisões importantes? • • • •

A decisão é unicamente identificada A decisão tem referência a um concern O responsável pela decisão é identificado Restrições e assumptions que influenciam a decisão são identificadas

Como documentar decisões importantes? • Alternativas consideradas são armazenadas • Consequências das decisões são documentadas • Tempos da decisão (quando foi tomada, aprovada, alterada) são identificados

Referência • INTERNATIONAL STANDARD ISO/IEC/ IEEE 42010.

O Papel do Arquiteto de Software

O Arquiteto “Your life is the sum of a remainder of an unbalanced equation inherent to the programming of the matrix. You are the eventuality of an anomaly, which despite my sincerest efforts I have been unable to eliminate from what is otherwise a harmony of mathematical precision. While it remains a burden assiduously avoided, it is not unexpected, and thus not beyond a measure of control. Which has led you, inexorably, here.”

Architects play a central role • Architects play a central role in software development, and must be multi-skilled in software engineering, technology, management and communications. • Architects must make design decisions early in a project lifecycle

O arquiteto de SW no ciclo de vida • O arquiteto de software tem grande influência em todas as fases do ciclo de vida do software

O arquiteto de SW no ciclo de vida • “The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark” – Kruchten – Decisões de tecnologia devem ser tomadas desde o início – Muitas possibilidades de tecnologias

Requisitos • Responsável por entender e gerenciar os requisitos não-funcionais. • Revisa e aprova os requisitos em nível de sistema • Trabalha diretamente com o cliente, o usuário, e o marketing, e dá suporte na formulação de requisitos.

Análise de Riscos • Provê a gerência e demais stakeholders com informação sobre os riscos técnicos do software. • Elabora plano de redução de riscos • Deve ser capaz de entender o impacto que as mudanças nos requisitos terão sobre o software, assim como o risco de propostas de mudanças.

Design • Projeto da estrutura geral do software assim como os componentes críticos, interfaces, e políticas de desenvolvimento. • Conjunto de diretivas para a equipe de desenvolvimento, assim como guias de estilo de codificação • Autoridade final em problemas e decisões como estilo de design e desenvolvimento, definição de interfaces, e modificações em requisitos.

Revisões • Revisa e aprova os vários deliverables do projeto. – Design de subsistemas – Definição de documentos de interfaces – Guias de codificação

• Revisa e aprova toda a documentação gerada.

Mentoring • Since the software architect is an expert developer and designer it is critical to share this knowledge and experience with the team. • This can be done in a number of different ways, including developing and teaching classes, individual help sessions, and seminars. • An occasional programming session.

Implementação • Implementation is a role that may be played by an architect on a small project. • An architect may be involved in initial prototyping efforts. • On large-scale projects there are simply too many high level issues for an architect to spend significant time in an implementation role. • The architect should not be personally responsible for code deliverables as this involvement may end up as a bottleneck for other developers.

Líder de equipe • Líder de um projeto, ou parte dos líderes. • Em grandes projetos o arquiteto de software pode ter uma equipe de suporte, ou participar de uma equipe de arquitetura. • Precisa liderar as equipes e mantê-los focados em solucionar os maiores riscos do projeto.

Skills, background, attributes

• Grande experiência em projeto e desenvolvimento de software – Deve entender e explicar como o design vai ser mapeado em implementação.

• Liderança técnica é chave para tomar decisões efetivas. – Os gerentes e desenvolvedores devem ser convencidos que as decisões tomadas pelo arquiteto de software são boas (ao menos baseado em informações atuais) – Deve ser reconhecido como um líder técnico.

Skills, background, attributes • Facilidade de trabalhar em equipe é essencial – Deve ser eficaz em liderar tanto a equipe de arquitetura quanto a de desenvolvimento. – Deve ser capaz de tomar a decisão final quando há desacordo técnico.

• Communication skills são vitais para o trabalho do arquiteto de software. – Deve prover uma direção clara para a equipe de arquitetura – Deve comunicar claramente as necessidades e preocupações da arquitetura do software aos stakeholders.

Skills, background, attributes • Technical skills devem ser amplos (em largura e profundidade) e atuais. – Deve ter a habilidade de fazer seleções de tecnologias que facilitem o desenvolvimento do projeto. – Deve tomar cuidado com líderes técnicos que querem impor uma tecnologia. – Deve evitar a tendência de escolher uma tecnologia por moda.

O que faz o arquiteto de software? • Define a arquitetura do software • Compreende requisitos e qualidades, extrai requisitos significativos em relação a arquitetura • Toma decisões, sintetiza uma solução, explora alternativas • Mantém a integridade da arquitetura do software através de revisões, guias, etc. • Apresenta a arquitetura para os diversos stakeholders, em diferentes níveis de abstração. • Identifica e analisa riscos.

O que faz o arquiteto de software? • Participa do planejamento do projeto. • Propôe a ordem e o conteúdo de cada iteração. • Participa da estimativa de esforço, tempo e do particionamento do software. • Trabalha ativamente com as equipes de design, implementação e integração • Resolve problemas além da arquitetura do software se necessário • Ajuda a equipe de marketing na definição dos produtos futuros, uma vez que têm conhecimento de o que é possível de ser feito.

Duties, Skills, and Knowledge of a Software Architect - SEI

• Crafting the right architecture to solve the problem at hand is only part of architects' responsibilities. They must also: – define, document, and communicate it – make sure everyone is using it, and using it correctly – make sure that it comes out in stages in a timely way so that the overall organization can make progress before it's complete – make sure the software and system architectures are in synchronization – act as the emissary of the architecture – make sure management understands it (to the detail necessary) – make sure the right modeling is being done, to know that qualities like performance are going to be met – give input as needed to issues like tool and environment selection – identify and interact with stakeholders to make sure their needs are being met – make sure that the architecture is not only the right one for operations, but also for deployment and sustainment – resolve disputes and make tradeoffs – resolve technical problems – maintain morale, both within the architecture group, and externally as well. The latter is done by providing a sound design, when needed, and providing good presentations and materials to let everyone know the organization is on the right track. – understand and plan for evolutionary paths – plan for new technology insertion – manage risk identification and risk mitigation strategies associated with the architecture

Vagas de arquiteto de software • • • •

• • • •

Qualifications Minimum:Education: MS degree in software engineering, computer science, or information systems or an equivalent combination of training and experience. Experience: Eight years of experience in software and systems development of substantial DoD, government, or industrial systems. Skills: At least three years of experience architecting software-intensive systems that includes managing quality attribute concerns (e.g., performance, modifiability, and scalability). Ability to assist with activities across the development lifecycle (including requirements, design, integration, and testing activities) and to effectively leverage architecture concepts in these activities. Knowledge of (preferably experience using) SEI architecture work such as the Architecture Trade-off Analysis Method, Quality Attribute Workshop, and documentation with the Views and Beyond Approach. Experience with the design and development of software-intensive systems, systems of systems, or mission-critical systems. Ability to analyze customer problems, determine needs, and recommend a course of action. Ability to quickly learn and adapt to new technologies, platforms, and environments. Knowledge of modern software development languages and platforms. Ability to work effectively with team members, customers, and collaborators. Effective written and oral communication skills. Environmental Conditions: Usual office setting, including extended work at a computer screen. Mental: Ability to meet deadlines and function productively as a team member. Preferred:Education: PhD degree in software engineering, computer science, or information systems or an equivalent combination of training and experience. Experience: Seven years, experience as listed above, plus experience working with industry and DoD stakeholders.

• •

Responsibilities: • Provide technical leadership of innovative, cutting-edge software projects • Lead software design, engineering, and architecture efforts • Partner with other technical leads and chief architects on architecting large-scale complicated solutions • Oversee risk mitigation around performance, data integrity, and scalability • Apply creative thinking/approach to determine technical solutions that further business goals, keeping in mind performance, reliability, scalability, usability, security, flexibility, and cost • Inspire people through his/her technical know-how • Skillfully identify problems and solve complex problems with simple solutions • Provide technical leadership to project teams, including setting the architecture vision and roadmap, being the primary contact for technical communications 

• •

Qualifications: • PhD in Computer Science required; consideration will also be given to individuals who have evidence of intellectual aptitude, innovation, effectiveness, and follow-through • 12 + years of extensive experience in building complex software projects, such as highly efficient real-time distributed datadriven systems • 8+ years of hands-on experience as technical lead of complex software projects, including designing, building, and providing technical oversight to the development team and to a lesser extent, working with the systems engineering team • 8+ years of proven expertise on being a Technical Lead of large-scale data-driven production systems that are heavily used • Demonstrated experience on creating prototypes of cutting-edge systems and designing/building a production-ready version • Expert knowledge in design of multi-tiered web systems • Training and experience in artificial intelligence, preferred • Ability to communicate ideas and provide direction to more junior staff • Application architecture/development experience with deep technology expertise in the following: o Extensive hands on design/coding experience/skills on architecture design of large scale platforms  o Strong service development experience with high performance and scalability o SQL/NoSQL technology o Web Services (REST/ SOAP) o Service Oriented Architecture o JavaScript Framework and AJAX

Porém.... • Arquiteto de Software Pleno - De R$ 4.001,00 a R$ 5.000,001 vaga: São Paulo - SP (1) • Desenhar a arquitetura da solução (diagrama de classes, diagrama de sequência). Atuar com modelagem de dados (MER). Desenhar a arquitetura de integrações. Atuar com definição e preparação do ambiente para hospedagem da solução. Conhecimentos técnicos em integração Rest, Apache, PHP7 e MySQL. Desejável ter conhecimentos em DB Aurora e Laravel. Ensino Superior.

Salários... • http://www.payscale.com/research/US/ Job=Software_Architect/Salary • Apple – média de U$189K • Oracle, IBM, Intel – U$170K • The typical Microsoft Software Architect salary is $179,535. Software Architect salaries at Microsoft can range from $152K - $213K.

Leitura • P. Kruchten, “What do software architects really do? ” Journal of Systems & Software, vol. 81, pp. 2413-2416, 2008 • Johan F. Hoorna, Rik Farenhorst, Patricia Lago, Hans van Vliet. The lonesome architect. The Journal of Systems and Software 84 (2011) 1424– 1435.

Leitura • https://spin.atomicobject.com/2015/02/19/so ftware-architect-role/ • https://www.stackoverflowbusiness.com/blog /how-to-find-and-hire-a-software-architect