|
|
# Introdução à Engenharia de Software
|
|
|
|
|
|
Programar não é muito difícil. Fazer seu programinha, seu projetinho, fazendo sozinho e depois você deixa lá guardado em geral não dá problema.
|
|
|
Programar não é muito difícil. Fazer seu programinha, seu projetinho, fazendo sozinho e depois você deixa lá guardado em geral não dá problema.
|
|
|
|
|
|
O único software que acaba é o que foi jogado no lixo. Todo software muda e precisa mudar, seja porque o ambiente mudou, a linguagem mudou, o chefe pediu um novo relatório, a empresa sofreu uma fusão ou a legislação que regulamenta a atividade mudou. Na vida real não é uma questão de SE o software vai mudar, é uma questão de QUANDO.
|
|
|
Mas na realidade o único software que acaba é o que foi jogado no lixo. Todo software muda e precisa mudar, seja porque o ambiente mudou, a versão da linguagem se tornou obsoleta, encontraram uma grave falha de segurança em uma das bibliotecas que o software precisava, o chefe pediu um novo relatório, a empresa sofreu uma fusão ou a legislação que regulamenta a atividade mudou. Na vida real não é uma questão de SE o software vai mudar, é uma questão de QUANDO.
|
|
|
|
|
|
E esse software é difícil de fazer. Principalmente com várias pessoas, é uma coleção de grandes e pequenas coisas que fazem a diferença na qualidade do software e na produtividade da equipe.
|
|
|
|
|
|
Hoje a maior parte das linguagens para esses sistemas usa programação orientada a objetos, uma tecnologia muito legal. Mas quando estudar ela você vai ver que ela aumenta muito a quantidade de maneiras diferentes que uma coisa pode ser feita, projetada, programada. E isso é ruim do ponto de vista de uma equipe de desenvolvimento. Alguém pode ter que mexer no seu código e ele precisa entender rápido como as coisas estão organizadas. Então é muito normal a criação de padrões nas equipes ou comunidades. Padrões de organização e gerenciamento de equipes, de codificação, e até respostas prontas de como modelar algumas relações de organização e interação de dados que aparecem repetidamente, esses são os "design patterns".
|
|
|
Hoje a maior parte das linguagens para esses sistemas usa programação orientada a objetos, uma tecnologia muito legal. Mas quando estudar ela você vai ver que ela aumenta em muito a quantidade de maneiras diferentes que uma coisa pode ser projetada e programada. E isso é ruim do ponto de vista de uma equipe de desenvolvimento. Alguém pode ter que mexer no seu código e ele precisa entender rápido como as coisas estão organizadas. Então é muito normal a criação de padrões nas equipes ou comunidades. Padrões de organização e gerenciamento de equipes, de codificação, e até respostas prontas de como modelar algumas relações de organização e interação de dados que aparecem repetidamente, esses são os "design patterns".
|
|
|
|
|
|
Até coisas bem relacionadas a codificação como nome de funcao_com_underscore ou funcaoEmCamelcase fazem diferença na prática da programação. Alguns padrões de codificação são apoiados por linguagens como a [PEP8](https://www.python.org/dev/peps/pep-0008/) pra python e o uso de camelcase em java, e alguns até viram parte da linguagem como XXX onde funções que serão exportadas para outros módulos tem que ter nome começando com letra maiuscula.
|
|
|
|
|
|
Até coisas bem relacionadas a codificação como nome de funcao_com_underscore ou funcaoEmCamelcase fazem diferença na prática da programação. Alguns padrões de codificação são apoiados por linguagens como a [PEP8](https://www.python.org/dev/peps/pep-0008/) pra python e o uso de camelcase em java e alguns até viram parte da linguagem como XXX onde funções que são públicas tem que ter nome começando com letra maiuscula.
|
|
|
|
|
|
O objetivo desse texto é explicar um pouco sobre MVC um desses padrões de organização do sistema.
|
|
|
|
... | ... | @@ -18,7 +19,7 @@ O objetivo desse texto é explicar um pouco sobre MVC um desses padrões de orga |
|
|
|
|
|
Para alguns exemplos vou usar um sistema/aplicativo financeiro.
|
|
|
|
|
|
Vou falar bastante de java pq em geral é de onde esses padrões vem e é onde eles fazem mais sentido.
|
|
|
Vou falar bastante de java porque em geral é de onde esses padrões vem e é onde eles fazem mais sentido.
|
|
|
|
|
|
É um pouco complicado falar de MVC e Django, mas ainda vale a pena entender a organização do MVC pro projeto.
|
|
|
|
... | ... | @@ -37,9 +38,9 @@ Ele é dividido em três partes: Model, View e Controller. Que funcionam como tr |
|
|
|
|
|
**Controller** faz a comunicação entre view, model e o ambiente. Por exemplo: é ele que recebe um formulário do cliente, ai pede pra model validar, processar, salvar no banco de dados, e depois pede pra view mostrar a mensagem de sucesso.
|
|
|
|
|
|
**Model** é a parte maior do sistema, é o que faria a parte pesada de calculos nos sistemas. Não é bem o nosso caso pq nossos calculos são feitos pelo pandas e guardados em uma forma da cache, mas . No mundo java costuma ser dividido em várias camadas pra lidar com diferentes tarefas. Por exemplo, em java:
|
|
|
**Model** é a parte maior do sistema, é o que faria a parte pesada de calculos nos sistemas. Não é bem o nosso caso porque nossos calculos são feitos pelo pandas e guardados em uma forma da cache, mas . No mundo java costuma ser dividido em várias camadas pra lidar com diferentes tarefas. Por exemplo, em java:
|
|
|
|
|
|
- uma camada de abstração de dados (DAO). O modo como os SGBDs retêm os dados e o modo como as linguagens ou frameworks retêm os dados e as ligações entre eles é bastante diferente, então é preciso ficam convertendo de um modo para o outro. Para evitar um inferno no código criamos uma série de funções para essas conversões e chamamos de camada DAO (data access object). Essa camada também cuida das conexões ao banco de dados. Em geral existem bibliotecas para fazer esse trabalho como:
|
|
|
- uma camada de abstração de dados (DAO). O modo como os SGBDs retêm os dados e o modo como as linguagens ou frameworks retêm os dados e as ligações entre eles é bastante diferente, então é preciso ficam convertendo de um modo para o outro. Para evitar um inferno no código criamos uma série de funções para essas conversões e chamamos de camada DAO (data access object). Essa camada também cuida das conexões ao banco de dados. Em geral existem bibliotecas para fazer esse trabalho como:
|
|
|
- [django query system](https://docs.djangoproject.com/en/1.11/topics/db/queries/) o que o django dá pra gente
|
|
|
- [SQLAlchemy](https://www.sqlalchemy.org/) é o framework mais geral pra isso em python
|
|
|
- [Hibernate](http://hibernate.org/) pra Java, é o mais famoso do ramo
|
... | ... | @@ -95,8 +96,8 @@ def controller_emprestimo(formulario): |
|
|
|
|
|
A ideia é que partes da model sejam reutilizáveis. No exemplo, um sistema bancário online e um aplicativo android desse banco para simular empréstimos (os dois usando java):
|
|
|
|
|
|
- a **view** é completamente diferente pq as tecnologias de visualização são diferentes (HTML x template XML do android)
|
|
|
- o **controller** também, pq o aplicativo não vai fazer todas as operações do sistema financeiro e o ambiente web é diferente de um aplicativo. Na web as coisas chegam como requisições HTTP já no aplicativo são outras formas de comunicação com o ambiente as coisas podem ficar em memória e não vem como requisições fechadas.
|
|
|
- a **view** é completamente diferente porque as tecnologias de visualização são diferentes (HTML x template XML do android)
|
|
|
- o **controller** também, porque o aplicativo não vai fazer todas as operações do sistema financeiro e o ambiente web é diferente de um aplicativo. Na web as coisas chegam como requisições HTTP já no aplicativo são outras formas de comunicação com o ambiente as coisas podem ficar em memória e não vem como requisições fechadas.
|
|
|
- **Model**:
|
|
|
- A validação pode mudar, em um sistema web existem mais maneiras de tentar burlar o sistema
|
|
|
- O DAO deve mudar, com o banco de dados diferente
|
... | ... | |