Essa aula foi lecionada pelo professor Pádua, que tratou da UML (Unified Modeling Language - Linguagem de Modelagem Unificada), uma linguagem de diagramação criada pela OMG (Object Management Group - Grupo de Gerenciamento de Objeto) que fornece uma notação gráfica para sistemas orientados a objetos.
Se procurarmos em um dicionário o significado de modelo, vamos encontrar o seguinte "forma típica para reproduzir ou imitar", o que vai de encontro com o principal propósito da UML: uma forma universal de reprodução de sistemas. Esta forma é baseada em diagramas. Em aula enfatizamos 2 tipos: Diagramas de Casos de Uso e Diagramas de Classes.
Diagramas de Casos de Uso:
Um caso de uso representa uma ação, sob um ponto de vista mais abrangente, que é iniciada por um ator (não necessariamente um ser humano, mas uma entidade externa ao sistema), ao qual oferece um resultado útil, concreto e observável. Desta forma, um diagrama de caso de uso é uma representação gráfica das interações entre os atores e os casos de uso (permita-se ler "recursos") que fazem parte de um sistema.
Para produzir um diagrama de casos de uso é sugerido que primeiramente sejam identificados os atores e em seguida os casos de usos. Representamos os atores por "bonequinhos de pauzinho" (aqueles primeiros modelos de pessoas que desenhávamos quando crianças) e os casos de usos por seus nomes (verbo + substantivo), cada um envolto por uma elipse. A última etapa consiste em conectar os atores aos casos de usos através de linhas.
Diagramas de Classes:
Uma classe (para fins de orientação a objetos) é uma entidade que agrupa objetos de características similares, lhes definindo atributos e métodos. Em um sistema composto por mais de uma classe, é interessante visualizarmos o relacionamento entre elas, e este é o objetivo dos diagramas de classes.
Em UML uma classe é representada graficamente por uma tabela de apenas uma coluna e três linhas. Na primeira escrevemos seu nome, na segunda seus atributos e na terceira os seus métodos. As classes podem se relacionar de três maneiras distintas: através de uma associação, uma agregação ou uma generalização.
Uma associação pode ser unária, binária ou múltipla e apresenta cardinalidade e navegação. É representada graficamente através de uma linha que pode conter setas sólidas em suas extremidades (navegabilidade).
Uma agregação é uma associação especial em que se passa a idéia de vinculação de classes, em que uma é "parte-de" outra. Representamos por uma linha com uma rombóide na extremidade conectada à classe que tem a outra como "parte-de" si.
Finalmente, a generalização (ou especialização) está relacionada à ideia de taxinomia ("é-uma"). Graficamente é representada por uma linha com uma rombóide sólida na extremidade conectada à super-classe (classe pai).
Wednesday, September 20, 2006
Monday, September 11, 2006
Aula 8 (v.2)
No início da aula nos foi fornecido um material que contém um modelo de cenários descrito através da linguagem de entidades e relacionamentos.
Em seguida percebemos a existência de triggers no modelo. Eles passam a idéia de episódios seqüências. Um episódio pode ser descrito por um cenário, que por sua vez cria a idéia de sub-cenários, o que possibilita a decomposição de cenários.
Um cenário A pode estar relacionado a um cenário B através de uma pré-condição, e a um cenário C através de uma relação pai-filho (sub-cenário). Um cenário também pode se relacionar a outro por uma exceção.
Vimos também duas estratégias de verificação: Ciclo Autor/Leitor e Ciclo de Inspeção. A primeira delas surgiu com SADT (Structure Analysis and Design Technique) e a segunda na década de 70 por Fagan, um funcionário da IBM.
No Ciclo de Inspeção (Fagan Inspection) existem quatro papéis: Moderador, Secretário, Autor e Revisor. Esta estratégia consiste em outras quatro atividades: Preparação, Leitura, Reunião e Revisão. De forma sucinta temos o autor preparando o documento, o revisor o lendo e assinalando os defeitos do documento em uma lista de itens, uma reunião para que o revisor apresente seus resultados ao autor, e ao final desta a geração de uma lista de correções. Desta forma os autores revisam o documento com base no que lhes foi apresentado pelos revisores.
Ao final da aula discutimos a Teoria Geral de Sistemas (TGS), destacando dois princípios de modelagem: as relações "parte-de" (decomposição) e "é-uma" (instanciação).
Nos foi apresentada uma grande dificuldade da orientação a objetos: a complexidade em descrever entidades da vida real em classes de objetos. Desta forma sistemas que eram criados de forma a serem re-utilizados futuramente acabaram por gerar enormes re-trabalhos, já que não houve, no início de implementações orientadas a objetos, estudos suficientes na criação de abstrações mais altas (uso de herança). Afim de conter esta situação a ótica foi voltada aos componentes. Os objetos vistos como componentes precisavam de mais uma classificação, já que tornavam-se redundates dentro de um sistema complexo. Daí a idéia de separar os aspectos dos objetos que os utilizam. Tal idéia de aspectos facilita a unificação de características que ficavam espalhadas nas classes (esta idéia foi originada pela Xerox).
Em seguida percebemos a existência de triggers no modelo. Eles passam a idéia de episódios seqüências. Um episódio pode ser descrito por um cenário, que por sua vez cria a idéia de sub-cenários, o que possibilita a decomposição de cenários.
Um cenário A pode estar relacionado a um cenário B através de uma pré-condição, e a um cenário C através de uma relação pai-filho (sub-cenário). Um cenário também pode se relacionar a outro por uma exceção.
Vimos também duas estratégias de verificação: Ciclo Autor/Leitor e Ciclo de Inspeção. A primeira delas surgiu com SADT (Structure Analysis and Design Technique) e a segunda na década de 70 por Fagan, um funcionário da IBM.
No Ciclo de Inspeção (Fagan Inspection) existem quatro papéis: Moderador, Secretário, Autor e Revisor. Esta estratégia consiste em outras quatro atividades: Preparação, Leitura, Reunião e Revisão. De forma sucinta temos o autor preparando o documento, o revisor o lendo e assinalando os defeitos do documento em uma lista de itens, uma reunião para que o revisor apresente seus resultados ao autor, e ao final desta a geração de uma lista de correções. Desta forma os autores revisam o documento com base no que lhes foi apresentado pelos revisores.
Ao final da aula discutimos a Teoria Geral de Sistemas (TGS), destacando dois princípios de modelagem: as relações "parte-de" (decomposição) e "é-uma" (instanciação).
Nos foi apresentada uma grande dificuldade da orientação a objetos: a complexidade em descrever entidades da vida real em classes de objetos. Desta forma sistemas que eram criados de forma a serem re-utilizados futuramente acabaram por gerar enormes re-trabalhos, já que não houve, no início de implementações orientadas a objetos, estudos suficientes na criação de abstrações mais altas (uso de herança). Afim de conter esta situação a ótica foi voltada aos componentes. Os objetos vistos como componentes precisavam de mais uma classificação, já que tornavam-se redundates dentro de um sistema complexo. Daí a idéia de separar os aspectos dos objetos que os utilizam. Tal idéia de aspectos facilita a unificação de características que ficavam espalhadas nas classes (esta idéia foi originada pela Xerox).
Subscribe to:
Posts (Atom)