ESCUELA : NOMBRES: METODOLOGÍA Y TECNOLOGÍA DE LA PROGRAMACIÓN II CICLO : Ing. Patricio Abad Espinoza OCTUBRE 2009 – FEBRERO 2010 Ciencias de la Computación BIMESTRE: I Bimestre
Capítulo I:  El modelado del software La necesidad de modelar Principios del modelado Modelado orientado a objetos Introducción a UML
1.1  La necesidad de modelar
Modelando software Las personas idóneas están muy ocupadas. Nunca es el momento oportuno. Los planetas no parecen alinearse Los esfuerzos de programación heroicos son leyenda en esta industria, y a menudo parece que la reacción apropiada en cualquier crisis es trabajar más duro .
Software de calidad
¿Qué es un modelo? Un modelo es una  SIMPLIFICACIÓN  de la realidad. Construímos modelos para  COMPRENDER  mejor el sistema que estamos desarrollando. Construimos modelos de  SISTEMAS COMPLEJOS  porque no podemos comprender el sistema en su totalidad.
1.2 Principios del modelado Primero: La elección acerca de qué modelos crear, tiene una profunda influencia sobre cómo se acomete un problema, y cómo se da forma a la solución.
Principio 1
1.2 Principios del modelado (2) Segundo: Todo modelo puede ser expresado con diferentes niveles de precisión
Principio 2
1.2 Principios del modelado (2) Tercero: Los mejores modelos están ligados a la realidad
Principio 3
Principio 4:  Un único modelo o vista no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes con múltiples puntos de vista.  1.2 Principios del modelado (3)
Principio 4
Modelos de software
1.3 Modelado en objetos La PO0 permite al lector describir el problema en términos del propio problema, en vez de en términos del sistema en el que se ejecutará el programa final.
Objetos Mundo real Software Estudiante Matrícula Asignatura Factura Libro Pago Record Académico Aula Evaluación
Conceptos OO Clase Herencia Objeto Método Mensaje Componentes
Objetos: Características Abstracción Encapsulamiento Principio de ocultación Polimorfismo Herencia
1.4 Introducción a UML UML es  un lenguaje para Visualizar Especificar Construir Documentar Los componentes de un sistema de software.
UML para Visualizar Comunica a otros los modelos conceptuales, los cuales estaría sujetos a error si no se entienden los modelos. Hay elementos de software imposibles de entender sin modelos. Un modelo explícito facilita la comunicación.
UML para especificar UML construye modelos precisos, claros y completos.
UML para Construir Los modelos UML pueden ser directamente traducidos a lenguajes de programación. Se mapea a Java, C++, Visual Basic, etc. Tablas en RDBMS o almacenamiento persistente en OODBMS Permite la ingeniería hacia adelante Permite la ingeniería inversa
UML para Documentar UML provee documentación para la arquitectura del sistema, Requerimientos, pruebas, planificación del proyecto y control de versiones.
Inputs to the UML Fusion Operation descriptions,  message numbering Before and after  conditions  Meyer Harel State  charts Wirfs-Brock Responsibilities Embley Singleton classes,  High - level view Odell Classification Object lifecycles Shlaer- Mellor  Gamma, et.al Frameworks, patterns,  notes Booch Rumbaugh Jacobson Selic, Gullekson, Ward ROOM (Real-Time  Object-Oriented Modeling)
 

Metodología de la Programación II El modelado del software

  • 1.
    ESCUELA : NOMBRES:METODOLOGÍA Y TECNOLOGÍA DE LA PROGRAMACIÓN II CICLO : Ing. Patricio Abad Espinoza OCTUBRE 2009 – FEBRERO 2010 Ciencias de la Computación BIMESTRE: I Bimestre
  • 2.
    Capítulo I: El modelado del software La necesidad de modelar Principios del modelado Modelado orientado a objetos Introducción a UML
  • 3.
    1.1 Lanecesidad de modelar
  • 4.
    Modelando software Laspersonas idóneas están muy ocupadas. Nunca es el momento oportuno. Los planetas no parecen alinearse Los esfuerzos de programación heroicos son leyenda en esta industria, y a menudo parece que la reacción apropiada en cualquier crisis es trabajar más duro .
  • 5.
  • 6.
    ¿Qué es unmodelo? Un modelo es una SIMPLIFICACIÓN de la realidad. Construímos modelos para COMPRENDER mejor el sistema que estamos desarrollando. Construimos modelos de SISTEMAS COMPLEJOS porque no podemos comprender el sistema en su totalidad.
  • 7.
    1.2 Principios delmodelado Primero: La elección acerca de qué modelos crear, tiene una profunda influencia sobre cómo se acomete un problema, y cómo se da forma a la solución.
  • 8.
  • 9.
    1.2 Principios delmodelado (2) Segundo: Todo modelo puede ser expresado con diferentes niveles de precisión
  • 10.
  • 11.
    1.2 Principios delmodelado (2) Tercero: Los mejores modelos están ligados a la realidad
  • 12.
  • 13.
    Principio 4: Un único modelo o vista no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes con múltiples puntos de vista. 1.2 Principios del modelado (3)
  • 14.
  • 15.
  • 16.
    1.3 Modelado enobjetos La PO0 permite al lector describir el problema en términos del propio problema, en vez de en términos del sistema en el que se ejecutará el programa final.
  • 17.
    Objetos Mundo realSoftware Estudiante Matrícula Asignatura Factura Libro Pago Record Académico Aula Evaluación
  • 18.
    Conceptos OO ClaseHerencia Objeto Método Mensaje Componentes
  • 19.
    Objetos: Características AbstracciónEncapsulamiento Principio de ocultación Polimorfismo Herencia
  • 20.
    1.4 Introducción aUML UML es un lenguaje para Visualizar Especificar Construir Documentar Los componentes de un sistema de software.
  • 21.
    UML para VisualizarComunica a otros los modelos conceptuales, los cuales estaría sujetos a error si no se entienden los modelos. Hay elementos de software imposibles de entender sin modelos. Un modelo explícito facilita la comunicación.
  • 22.
    UML para especificarUML construye modelos precisos, claros y completos.
  • 23.
    UML para ConstruirLos modelos UML pueden ser directamente traducidos a lenguajes de programación. Se mapea a Java, C++, Visual Basic, etc. Tablas en RDBMS o almacenamiento persistente en OODBMS Permite la ingeniería hacia adelante Permite la ingeniería inversa
  • 24.
    UML para DocumentarUML provee documentación para la arquitectura del sistema, Requerimientos, pruebas, planificación del proyecto y control de versiones.
  • 25.
    Inputs to theUML Fusion Operation descriptions, message numbering Before and after conditions Meyer Harel State charts Wirfs-Brock Responsibilities Embley Singleton classes, High - level view Odell Classification Object lifecycles Shlaer- Mellor Gamma, et.al Frameworks, patterns, notes Booch Rumbaugh Jacobson Selic, Gullekson, Ward ROOM (Real-Time Object-Oriented Modeling)
  • 26.

Notas del editor

  • #2 utpl
  • #3 utpl
  • #22 Essentials of Visual Modeling w/ UML 2.0 - Instructor Notes Typically, projects and organizations develop their own language for modeling systems, making it difficult for outsiders and new team members to understand what is going on. Communicating these conceptual models to others is prone to error unless everyone involved speaks the same language. The UML offers a set of symbols that represents well-defined semantics. One developer can write a model in the UML, and another developer can interpret that model unambiguously. There are things about a software system you can’t understand unless you build models that transcend the textual programming language. For example, the meaning of a class hierarchy can be inferred, but not directly grasped, by staring at the code for all the classes in the hierarchy. The UML is a graphical language that addresses this problem. If the developer who cut the code never wrote down the models, the information would be lost forever. At best, the information would only be partially recoverable from the implementation after the developer has moved on. Writing models in the UML addresses this issue. An explicit model facilitates communication. ( The Unified Modeling Language User Guide , Booch, 1999.) Stress how the UML is designed to promote communication using pictures rather than text. Using the UML allows the “light bulb” to go on in the minds of many people. Rather than trying to interpret a textual description of a system design, the UML offers a graphical representation of that same description. In this case, a picture is truly worth a thousand words.
  • #23 Essentials of Visual Modeling w/ UML 2.0 - Instructor Notes In this context, specifying means to build models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made to develop and deploy software-intensive systems. ( The Unified Modeling Language User Guide , Booch, 1999.) The UML can be used to specify detailed or general models. Anyone who has worked on a project where miscommunication occurred appreciates this feature of the UML. The UML allows the modeler to specify their intentions in a clear, unmistakable manner.
  • #24 Essentials of Visual Modeling w/ UML 2.0 - Instructor Notes The UML is not a visual programming language. However, models using the UML can be directly connected to a variety of programming languages, making it possible to map from a model in the UML to a programming language or even to a database. If it is best expressed graphically, it is done graphically in the UML. If it is best expressed textually, it is done in the programming language. This mapping permits forward engineering : the generation of code from a UML model to a programming language. Reverse engineering is also possible: the reconstruction of a model from implementation back into the UML. The UML was designed with forward and reverse engineering in mind. Rational has partners who provide round-trip engineering for other languages.
  • #25 Essentials of Visual Modeling w/ UML 2.0 - Instructor Notes Project artifacts are critical in controlling, measuring, and communicating about a system during its development and after its deployment. The UML addresses the documentation of a system’s architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management. ( The Unified Modeling Language User Guide , Booch, 1999.) This slide does not represent all the diagrams defined in the UML specification. For example, there is no graphic presented here for a composite structure diagram or a timing diagram. Composite structure is a more advanced modeling concept that is not covered in this course. The timing diagram is new to UML2 and will be introduced in a later module. UML diagrams should be treated as formal project artifacts. Each diagram created by a project team should be treated as an artifact. The UML can help alleviate some of the paper crunch that many software teams experience.
  • #26 Essentials of Visual Modeling w/ UML 2.0 - Instructor Notes UML development included incorporating ideas from numerous other methodologists. The main challenge was to construct an approach that was simple, yet allowed the modeling of a broad range of systems. The conceptual framework was established quickly, but the notational semantics took more time. Active collaboration with other industry leaders has brought unique expertise and experience into the UML effort. The UML effort was supported by a cross-section of the industry. Partners in the UML effort included HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software, Taskon, and Unisys. These partners provided contributors, reviewers, and advocates for the standardization efforts. In the end, a modeling language was created that has already withstood the test of widespread use in the industry and the scrutiny of international standardization efforts. Demonstrate that UML was developed as an industry standard with many influences. The UML is not owned and written by Rational. Do not spend a lot of time on this slide. Simply point out one or two contributors of special interest to your audience. For example, for a telephony audience, you might point out Harel and his state charts.