[Música] o olá eu sou professor marcelo fantinato é que a disciplina de engenharia de software do curso de engenharia da computação da univesp nós vamos agora tratar a aula número 10 de modelos estruturais nós estamos em uma sequência de três aulas em que nós estamos tratando o modelo de software modelo de sistemas dentro do ciclo de engenharia de software e agora então nós vamos falar um pouco sobre modelos estruturais na aula anterior nós já falamos de dois tipos de modelo nós podemos ter um modelo de contexto que trata o modelo num nível bem alto bem
abstrato para a gente entender que o grande objetivo do sistema fronteira com que o sistema vai interagir os grandes processos que o sistema vai dar apoio depois os modelos começam a descer um pouco mais o nível modelo de interação como que as coisas acontecem dentro do sistema em termos de interação e aí novos modelos de casos de uso como os atores interagem com o sistema tanto no nível um pouco mais alto pensando na grande funcionalidade representado pelos casos de uso e depois dentro de cada caso de um que acontece e aí a gente começa a
ver que diferentes diagramas podem ser usados em diferentes níveis por exemplo nós vimos um carro um diagrama de classes que aparece num modelo de contexto muito alto nível de cada classe está representando um sistema e nós já estou adiantando aqui depois volto um pouco nós vamos ver aqui um outro diagrama de classe em que cada classe já para apresenta uma entidade mais específica do sistema então isso é importante que fique bastante claro para vocês que o mesmo diagrama do ml nós temos lá por volta de 15h gramas e cada diagrama ele representa um tipo de
informação uma visão diferente de informação e além disso essas informações podem estar bem diferente vivem então nós vimos um diagrama de classe num nível bem alto cada classe representa um sistema agora nós vamos ver aqui um diagrama de classe no nível intermediário cada classe representa uma entidade no nível é do do tema para que o o cliente usuário entenda e depois quando estiver tratando no projeto mais para frente nós vamos ver um nível ainda mais baixo que no nível já da implementação então isso é uma coisa importante de se entender que diferentes diagramas representam diferentes
tipos de informação um mesmo diagrama pode representar diferentes níveis de abstração e uma outra coisa que eu ainda não é explorar bastante com vocês na aula anterior e nessa mas eu já explorei no início da disciplina é vocês não precisam usar tudo todos os diagramas do iml em todos os níveis necessários vocês não precisam necessariamente ter um modelo de contexto modelo de interação modelo comportamental modelo de estrutura lembrando daquilo que foi estressado lá no início das primeiras aulas são idéias são práticas vocês devem entender para poder lembrar delas e ver onde elas se aplicam para
ajudá los porque então em termos de modelos estruturais que é o terceiro tipo de modelo que vocês podem usar para que um modelo estrutural ele serve ele serve para organizar o sistema em termos de seus componentes e seus relacionamento então ele representa a estrutura do sistema estrutura do software você tem um sistema que você quer desenvolver esse sistema tem um conjunto de componentes e esses componentes eles têm relacionamento entre si basicamente de alguma forma a gente quer representar isso esse desenho aqui ele não ajudou muita coisa porque é é um nível de abstração muito alto
então a oms ela permite você fazer isso de uma forma mais bem definida de forma mais estruturada diagrama diagrama de 47 o melhor de a grama para você definir a estrutura de um sistema aqui nós temos as principais entidades do sistema então nós estamos falando daquele sistema de gerenciamento de um sistema de gerenciamento de uma clínica médica de de saúde mental e quais são as principais entidades relacionadas a esse sistema então nós temos o paciente a paciente que a entidade principal é esse paciente ele por exemplo vai frequentar uma consulta então e o paciente frequenta
uma consulta um paciente pode freqüentar uma ou mais consultas uma consulta é frequentada por um mais pacientes essa consulta é realizada por um médico do hospital nesse caso aqui especificamente foi modelado que até quatro médicos podem realizar uma consulta e um médico pode realizar de uma apn consultas então esse modelo ele permite você definir quais são as entidades e qual a relação entre as entidades esse durante a consulta essa consulta vai ter a prescrição de uma medicação um ou mais e também um mais tratamento há dois tipos de prescrição durante a consulta a esse paciente
ele vem indicado por um clínico geral ok porque nós estamos tratando de um de uma especialidade que é uma técnica de saúde mental e espera-se que um clínico geral têm indicado esse paciente aac tamanho dela está modelada desta forma na prática a gente sabe que isso não necessariamente acontece mas nesse modelo aqui necessariamente esse paciente tem que ter indicado por um clínico geral então é são características do modelo poderia ter aqui zero ou um não a gente mas aqui está dizendo que é enfim são características da anotação que você pode definir exatamente como o sistema
tem que atuar é esse paciente é diagnosticado com uma determinada condição ou mais do que uma enfim aqui nós temos agora percebo que aqui de novo nós estamos num nível bem alto isso aqui ainda não dá plenas condições para a implementação do sistema isso aqui o objetivo desse modelo é você entender como o software tem uma estrutura num nível alto em um nível mais alto é pra que ainda o os analistas de rede e vitor e há os analistas de sistemas nível mais alto tem uma visão bastante clara de como o software deve ser pra
poder inclusive vai lidar com o cliente para que o cliente por exemplo diga não não tem que ter necessariamente um clínico geral pode ter e eu preciso se tiver eu quero representar isso no banco de dados mas pode ser que não tenha nenhum então você modela isso de acordo com que você entendeu e aí a hora que você estava lidando isso com o cliente o cliente fala não eu não preciso de necessariamente um clínico geral então você pode ter esse tipo de feedback quando você faz isso você vai refinar isso mais de forma a que
em algum momento você tem um diagrama que é muito que é basicamente a entrada para fazer a implementação do software vocês devem ter visto esse tipo de diagramas diagrama de classe na disciplina de pior na programação orientada a objetos que você verão em algum mestre anterior talvez lá vocês têm visto já o diagrama é no nível mais baixo já pensando na programação não sei se vocês chegaram a ver o diagrama da mls você trabalhar já no nível de código propriamente dito direto certamente vocês viram a idéia a noção de classe essa classe cada uma dessas
classes aqui nós podemos dividir então nos atributos e nos métodos nós estamos falando aqui da classe consulta como exemplo então essa classe consulta ela tem os vários atributos os vários métodos que representa as operações então eu não sei vocês viam nessa notação gráfica usando o ml mas com certeza a nota a noção do que é uma classe dividida em atributos métodos que vai poder ser financiado em vários objetos e só tem praticamente certeza que vocês viram na disciplina ok de qualquer forma mesmo que lá vocês tenham visto a idéia da da notação gráfica vocês viram
um num nível mais baixo nível aqui nós ainda estamos pensando como é uma consulta o que é uma consulta essa consulta envolve médicos uma data ou horário uma acontece numa clínica tem um motivo uma medicação prescrita tratamento anotações de voto transcrições e aí você já começa a pensar também em algumas operações algumas ações que acontecem nessa consulta você pode prescrever algo você pode registrar anotações transcrever algo mas perceba que você ainda não tem os detalhes que vocês costumam pena que vocês precisam ter na hora que você estão programando por exemplo esses atributos a que não
necessariamente já tem que ter o seu tipo é assim como o método também não têm tipos de de parâmetros argumentos enfim eu há neste momento ainda não quero detalhar tanto não preciso porque eu só quero ir entendendo melhor como o software como o sistema ele vai se estruturar ok e aí também conceitos que vocês devem ter visto já em ninguém em programação orientada a objetos e pior e que às vezes vocês também deve ter visto um nível bem mais baixo nível a que ele está entendendo que desde o início você já pode usar esses conceitos
é por exemplo a a generalização especialização o que não sei vocês aprenderam já com esse nome em termos de programação orientada a objetos está implementado como hierarquia aqui nós usamos esse diagrama é na verdade nós estamos ainda pensando dentro do diagrama de classes mas dentro do diagrama de 4 uma dessas quatro daqui então ela pode ser usar o conceito de de generalização né que é um médico por exemplo ele pode ser de dois tipos ele pode ser um clínico geral ou ele pode ser um médico que trabalha no hospital esse método de trabalho no hospital
pode ser um consultor ou ele pode fazer parte da equipe médica e um médico da equipe médica pode ter uma equipe com médico residente hoje pode ser um médico qualificado então é uma forma de você define a hierarquia de médicos e isso a gente chama de generalização especialização porque subir a gente está generalizando e dezenas gente está especializando ea forma de você define isso é através desse desse relacionamento aqui esse tipo de relacionamento então nós chamamos de relacionamento de generalização especialização e aí percebo no diagrama de atividades que nós vimos na aula anterior nós tínhamos
um determinado tipo de notação no diagrama de quatro nós temos outro tipo de notação então dependendo do diagrama você tem que saber exatamente o tipo de notação que vocês podem usar ainda ainda no enterro de generalização a generalização você pode manter as classes num nível intensificado ou cada uma dessas classes pode estar dividido mostrando os atributos e os métodos como aqui por exemplo ea gente sabe que quando a nós temos relacionamento generalização especialização as classes especialistas eram os atributos e os métodos então um médico do hospital tem um número da equipe o número do pedido
o nome telefone e mail o clínico geral tem nome roni e meio ea experiência o endereço mas não tem o número da equipe que nenhum membro do texto vocês devem se lembrar disso em termos de herança na implementação temos também a associação por agregação de um outro tipo de relacionamento que pode vestir no diagrama de classe a agregação ela não é é diferente né da generalização obviamente que estava vendo ela significa que há uma entidade no caso aqui uma classe ela é formada por arte então um registro de paciente é formado pelos dados do paciente
que pelos dados da consulta é isso no ar o exemplo do dia do mundo real nossa por exemplo uma bicicleta é formado pelo pedal pela roda pelos pneus então o que forma uma entidade de bicicleta cada uma das partes o que forma uma entidade carro motor pneus rodas bancos enfim é a composição por agregação então é diferente de você dizer tentando sair no evento o carro por exemplo um carro ele pode ter de vários tipos você pode ter um carro que é do tipo pick-up um carro que é do tipo s dão um carro que
é do tipo hatch um carro do tipo piro então especializações de um carro isso é a generalização especialização que a gente viu slide anterior e o associação por agregação que a gente está vendo aqui é o carro é formado por diferentes partes então esses dois tipos de relacionamento eles podem ser usado no diagrama de classes pra gente entender melhor como que as entidades elas se relacionam um diagrama de classes justamente para nós entendermos melhor a aaa o software que desenvolve e aqui também existe o relato a cardinal idade né o registro do paciente é formado
por um único paciente agora esse registro do paciente é formado por uma ou mais consultas bons e com isso então é nós finalizamos aqui essa visão geral sobre modelos estruturais que lhes dão uma é uma forma de você representar a estrutura que o software vai ter quais as partes que o software o sistema vai ter e o principal é representante para você definir um modelo estrutural é o diagrama de classes do iml lembrando que neste momento nós estamos ainda tratando um diagrama alto unidos em detalhes de implementação ainda porque a gente quer ir refinando esses
detalhes agregando mais detalhes conforme vai passando de equipe para a equipe até porque nesse momento você pode ter analista de sistemas mais próximo do negócio mais próximo do cliente do que da implementação propriamente dita abril [Música] [Música] [Música] [Música] e a minha mãe
