Sunteți pe pagina 1din 5

Estudiantes del Quinto Ciclo de la Escuela Profesional de Ingeniería de Sistemas

Universidad Católica los Ángeles de Chimbote

Actividad:

Actividad N° 4 Informe de trabajo colaborativo

Asignatura:

Ingeniería Software I

Docente:

Mg. Ing. Luis Armando Saavedra Yarleque

Estudiantes:

Calle Yenque Elizabeth

Erazo Salas Carlos Eduardo

Vinces Silva Davis

Parrilla Acha Wilton Alfredo

Filial -Piura

2019
El modelo estático UML

Como sabemos, para el análisis y los diseños orientados a objetos utilizaremos los
conceptos y las notaciones esencialmente gráficas del UML. El UML comprende un cierto
número de diagramas interrelacionados mediante conceptos comunes. Sólo para
describirlos, los consideraremos agrupados en tres modelos:

1. Estático: describe la estructura de clases y objetos.


2. Dinámico: Modelo de comportamiento, describe las interacciones entre los
objetos dentro den software.
3. Implementación: Describe la estructura del software cuanto a los
componentes de que consta y su ubicación.

Veremos el modelo estático, que consta, por una parte, de clases y objetos, y por la otra,
de relaciones de diferentes tipos entre clases y entre objetos. En capítulos posteriores
trataremos el resto de los modelos y la utilización del UML en el análisis y en el diseño.

1. Concepto de modelo estático y diagrama de clases


Describe la estructura y las restricciones de la información que representa el estado del
sistema la valoración de inversiones es el proceso de planificación utilizado para
determinar si una empresa debe acometer una inversión a largo plazo, como nueva
maquinaria, maquinaria de repuesto, nuevas instalaciones, nuevos productos y proyectos
de investigación.

Para ello se construyen los modelos, normalmente una simplificación de la realidad.


Surgen de un análisis de todas las variables intervinientes en el sistema y de las relaciones
que se descubren existen entre ellas.

Ejemplo de modelo estático Un diagrama estático nos puede mostrar que cada profesor
tiene, al menos, una asignatura, y que cada asignatura tiene, al menos, un profesor, pero
no nos dice qué asignaturas tiene un profesor concreto.

Este modelo consta de los dos diagramas siguientes:

 Diagrama de clases, que puede contener clases y objetos y relaciones entre éstos,
y que se hace siempre.
 Diagrama de objetos, que sólo contiene objetos y relaciones entre éstos, y que es
opcional, ya que se utiliza principalmente para realizar ejemplos del diagrama
Uso del modelo estático

El modelo estático pretende ser independiente del lenguaje de programación, pero, sin
embargo, si se sabe cuál será, es conveniente no utilizarlo en el análisis de conceptos que
sabemos que dicho lenguaje no soporta, si queremos ahorrarnos muchos cambios cuando
lleguemos al diseño. También se deberá tener en cuenta que, cuando el UML permite
describir elementos incompatibles con un lenguaje determinado, raramente la
herramienta CASE nos lo impedirá; por lo tanto, será responsabilidad del diseñador del
software evitar caer en la utilización de conceptos no soportados por el lenguaje de
programación.(1)

Relaciones en los lenguajes de programación

En informática, se conoce como lenguaje de programación a un programa destinado a la


construcción de otros programas informáticos. Su nombre se debe a que comprende un
lenguaje formal que está diseñado para organizar algoritmos y procesos lógicos que serán
luego llevados a cabo por un ordenador o sistema informático, permitiendo controlar así
su comportamiento físico, lógico y su comunicación con el usuario.

2. Clasificadores El clasificador es la entidad básica del modelo estático. Un clasificador


es más general que una clase; es un conjunto cuyos elementos se denominan instancias.
El clasificador en sí mismo no tiene símbolo gráfico, sino que lo tienen sus estereotipos:
Clase:

 El concepto de clase es el que ya conocemos de la programación orientada a


objetos, y sus instancias son los objetos, que tienen identidad, en el sentido de que
incluso dos objetos que coinciden en el valor de todos sus atributos son objetos
diferentes si se han creado como tales.
 Tipo de dato: Por tipo de dato entendemos un tipo base ofrecido por algún
lenguaje de programación o construido por el programador; tiene operaciones
asociadas igual que las clases, pero sus instancias, a diferencia de los objetos, no
tienen identidad.
 Interfaz: Una interfaz sólo describe las operaciones de una clase que son visibles
desde otras clases; se dice que dicha clase implementa la interfaz correspondiente.
Clase: El concepto de clase es el que ya conocemos de la programación orientada a
objetos, y sus instancias son los objetos, que tienen identidad, en el sentido de que incluso
dos objetos que coinciden en el valor de todos sus atributos son objetos diferentes si se
han creado como tales.

Tipo de dato: Por tipo de dato entendemos un tipo base ofrecido por algún lenguaje de
programación o construido por el programador; tiene operaciones asociadas igual que las
clases, pero sus instancias, a diferencia de los objetos, no tienen identidad. Interfaz: Una
interfaz sólo describe las operaciones de una clase que son visibles desde otras clases; se
dice que dicha clase implementa la interfaz correspondiente.

2. Paquetes Un paquete o package es sólo una “caja” que contiene elementos, como
clasificadores, objetos u otros paquetes, así como otras entidades que veremos
más adelante, como los casos de uso.
Paquetes en JAVA Por la definición que ofrecemos de paquete, podemos ver que
el concepto de paquete en el UML es diferente y más amplio que en Java
En la primera, se pueden incluir dentro del símbolo del paquete los símbolos de
los elementos que contiene; la segunda, simplificada, es más adecuada para
representar referencias al paquete (desde otros paquetes, por ejemplo). Se pueden
establecer los siguientes tipos de relaciones entre paquetes:
• De especialización. Si un paquete A hereda de otro B todos los elementos de B
, son casos más restrictivos de elementos de A .
De inclusión. Si el paquete A incluye el B, todos los elementos de B están también
en A. (2)
Bibliografía

1. Campderrich Falgueras B. Ingeniería del software. Barcelona: Editorial UOC;


2003.
2. Almonacid Arismendi R, Hernández Venega S. Programación orientada a
aspectos informe final de habilitación profesional. Santiago de Chile: D -
Universidad del Bío-Bío; 2009.

S-ar putea să vă placă și