basic concepts the unified modeling language uml n.
Skip this Video
Loading SlideShow in 5 Seconds..
Basic Concepts The Unified Modeling Language (UML) PowerPoint Presentation
Download Presentation
Basic Concepts The Unified Modeling Language (UML)

Loading in 2 Seconds...

play fullscreen
1 / 20

Basic Concepts The Unified Modeling Language (UML) - PowerPoint PPT Presentation

Download Presentation
Basic Concepts The Unified Modeling Language (UML)
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Basic ConceptsThe Unified Modeling Language (UML) SYSC 3100 - System Analysis and Design

  2. What is a model? • You must have made or played with one as a child.  • Have you wandered through architecture?

  3. Objectives • Explain the need for models in Engineering work • Describe the purpose of the Unified Modeling Language • Explain the difference between a model and a diagram. • Explain the views and their corresponding diagrams • Structure • Dynamic • Physical • Management We will concern ourselves with 1 and 2 mainly.

  4. Models in Traditional Engineering • As old as engineering • Traditional means of reducing engineering risk IBM Software Group |

  5. Engineering Models • Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint • We don’t see everything at once • We use a representation (notation) that is easily understood IBM Software Group |

  6. How Engineering Models are Used • To help us understand complex systems • Useful for both requirements and designs • Minimize risk by detecting errors and omissions early in the design cycle (at low cost) • Through analysis and experimentation • Investigate and compare alternative solutions • To communicate understanding • Stakeholders: Clients, users, implementers, testers, documenters, etc. • To drive implementation • The model as a blueprint for construction IBM Software Group |

  7. . . . A Common Problem with Engineering Models • Semantic Gap due to: • Idiosyncrasies of actual construction materials • Construction methods • Scaling effects • Skill sets • Misunderstandings • Can lead to serious errors and discrepancies in the realization Common Problem IBM Software Group |

  8. Modeling and UML • The idea of modelling is fundamental to UML • Like a map, a model represents something else • A useful model has the right level of detail and represents only what is important for the task in hand • Many things can be modelled: bridges, traffic flow, buildings, economic policy

  9. Why Use a Model? • A model is quicker and easier to build • A model can be used in a simulation • A model can evolve as we learn • We can choose which details to include in a model • A model can represent real or imaginary things from any domain

  10. UML and Diagrams • In software engineering, like in other engineering disciplines, we use diagrams to represent models … • Abstract shapes are used to represent things or actions from the real world, or from a system in our case … • Diagrams follow rules or standards • The standards make sure that different people will interpret the diagram in the same way 40°

  11. What is UML? • Specification and design language, not a programming language! Modeling language. • Mostly visual but has precise semantics • Diagrams consist of well-defined elements (graphical) and have rules on how to use and combine elements • Abstract syntax, well-formedness rules, semantics can be found in the official documentation • UML is not a CASE tool. Rather, many CASE tools support UML modeling, code generation, simulation of UML models, etc. (e.g., Rational Rose) • UML is not a methodology but only a notation

  12. Origins and Future of UML • Object-oriented programming languages: Simula (67), C++, Eiffel, Java … • Object-oriented Analysis and Design techniques • UML’s goal was to bring together the best features of all notations to produce an industry standard • UML is (mostly) a visual, modeling language • The course (and textbook) will use UML 2.0

  13. Why use UML? • Diagrams help visualize designs and cope with complexity • Abstract features of the design • Show relationships between elements of the design • Implements or support the principles of: • Abstraction • Separation of concerns • Modularity • Rigor and formality • De facto standard for object-oriented modeling • Bring good ideas in consistent framework, supported by many tools, profiles, methods and processes exist

  14. Diagrams vs Models • A diagram illustrates some aspect of a system. • A model provides a complete view of a system at a particular stage and from a particular perspective, e.g., Analysis model, Design model. • A model may consist of a single diagram, but most consist of many related diagrams and supporting data and documentation.

  15. Models in UML • A system is the overall thing that is being modelled • A sub-system is a part of a system consisting of related elements • A model is an abstraction of a system or sub-system from a particular perspective • A model is complete and consistent at the chosen level of abstraction

  16. UML Views • A view is a subset of UML modelling constructs that represents one aspect of a system. The views used in this section are not part of UML specification but just an aid to organizing and presenting the UML concepts. • Structural classification • Dynamic behaviour • Physical layout • Model management James Rumbaugh et. al

  17. UML views and diagrams

  18. UML views and diagrams cont.

  19. UML views and diagrams cont.

  20. Summary • Models reduce risk. • Unified Modeling Language – Blueprints for designing software systems. (a bit bloated though) • Diagrams are used to express design in a common format. • Models are used to analyze the design. • Structure diagrams show static architecture. • Dynamic diagrams show how components interact. • Component diagrams show how architecture is mapped to hardware. • We don’t care about Management diagrams.