1 / 36

UML: An Introduction

Contents. Why model ?Principles of modelingWhat is UML ?Building Blocks. What is modeling . Modeling involves : Representation or simplification of realityProviding a blueprint of a system.. Why Model ?. Better understand the system we are developing Describe the structure or behavior of the s

daniel_millan
Download Presentation

UML: An Introduction

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. UML: An Introduction

    2. Contents Why model ? Principles of modeling What is UML ? Building Blocks

    3. What is modeling Modeling involves : Representation or simplification of reality Providing a blueprint of a system.

    4. Why Model ? Better understand the system we are developing Describe the structure or behavior of the system Experiment by exploring multiple solution Document the design solution Visualize the system “as_is” and “to_be” Provide a template for constructing a system.

    5. Principles of Modeling Choose your model well - the choice of model profoundly impacts the analysis of the problem and the design of the solution. Every model may be expressed at different levels of precision - the same model can be scaled up (or down) to different granularities. The best models are connected to reality - simplify the model, but don’t hide important details. No single model suffices - every nontrivial system has different dimensions to the problem and its solution. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "simplifying" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "simplifying" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.

    6. What is UML ? UML - Unified Modeling language Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "simplifying" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "simplifying" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.

    7. More on UML... Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.

    8. More on UML... Specifying - UML provides the means to model precisely, unambiguously and completely, the system in question. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.

    9. More on UML... Documenting - every software project involves a lot of documentation - from the inception phase to the deliverables. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.

    10. UML Building Blocks Elements Relationships Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all. Choose your model well: ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution OOAD will yield object-centered solution Granularities: The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times. Connected to reality: very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others No single model suffices: Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.

    11. Structural elements The nouns of UML models; usually the static parts of the system in question. Class - an abstraction of a set of elements in the problem-domain that have similar properties and/or functionality. Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)

    12. Structural elements (contd.) Collaboration - a collection of UML building blocks (classes, interfaces, relationships) that work together to provide some functionality within the system. Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)

    13. Structural elements (contd.) Active Class - a class whose instance is an active object; an active object is an object that owns a process or thread (units of execution) Component : a physical part of the system - typically a piece of software - like a library, an executable or even an ordinary document.Component : a physical part of the system - typically a piece of software - like a library, an executable or even an ordinary document.

    14. Structural elements (contd.) Node - a physical element that exists at run-time and represents a computational resource (typically, hardware resources). Component : a physical part of the system - typically a piece of software - like a library, an executable or even an ordinary document.Component : a physical part of the system - typically a piece of software - like a library, an executable or even an ordinary document.

    15. Behavioral elements The verbs of UML models; usually the dynamic parts of the system in question. Interaction - some behavior constituted by messages exchanged among objects; the exchange of messages is with a view to achieving some purpose.

    16. Behavioral elements (contd.) State machine - a behaviour that specifies the sequence of “states” an object goes through, during its lifetime. A “state” is a condition or situation during the lifetime of an object during which it exhibits certain characteristics and/or performs some function. State machine diagrams are especially relevant if the model pertains to/involves systems like digital/logic circuits where an element changes its "state" due to some inputState machine diagrams are especially relevant if the model pertains to/involves systems like digital/logic circuits where an element changes its "state" due to some input

    17. Grouping elements The organizational part of the UML model; provides a higher level of abstraction (granularity). Package - a general-purpose element that comprises UML elements - structural, behavioral or even grouping elements. Packages are conceptual groupings of the system and need not necessarily be implemented as cohesive software modules.

    18. Annotational elements The explanatory part of the UML model; adds information/meaning to the model elements. Note - a graphical notation for attaching constraints and/or comments to elements of the model.

    19. Relationships Articulates the meaning of the links between elements. Dependency - a semantic relationship where a change in one element (the independent element) causes a change in the semantics of the other element (the dependent element). Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)

    20. Relationships (contd.) Generalization - a relationship between a general element (called “parent” or “superclass”) and a more specific kind of that element (called the “child” or “subclass”), such that the latter can substitute the former. Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain) Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)

    21. Relationships (contd.) Realization - a semantic relationship between two elements wherein one specifies the behaviour to be carried out, and the other carries out the behaviour. “ a collaboration realizes a Use Case” the Use Case specifies the behaviour (functionality) to be carried out (provided), and the collaboration actually implements that behaviour. One generally talks of a component or a class "realizing an interface". What this means, is that the component or class in question guarantees to provide or perform or carry out the functionality/operation that the interface announces it will be carrying out.One generally talks of a component or a class "realizing an interface". What this means, is that the component or class in question guarantees to provide or perform or carry out the functionality/operation that the interface announces it will be carrying out.

    22. Diagrams The graphical presentation of the model. Represented as a connected graph - vertices (elements ) connected by arcs (relationships). UML includes nine diagrams - each capturing a different dimension of a software-system architecture. Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".

    23. Rational Rose

    24. What is Rational Rose? ROSE = Rational Object Oriented Software Engineering Rational Rose is a set of visual modeling tools for development of object oriented software.

    26. Parts of the Screen: Browser: Used to quickly navigate through the model. Documentation window: Used to view or update documentation of model elements. Toolbars: Used for quick access to commonly used commands. Diagram window: Used to display and edit one or more UML diagrams. Log: Used to view errors and report the results of various commands.

    27. Browser The browser is a hierarchical structure you can use to easily navigate through your Rose model. Anything you add to the model—actors, use cases, classes, components, and so on—will display in the browser There are four views in the browser: Use Case view, Logical view, Component view Deployment view.

    28. use case view It focuses what the system will do ,without worrying about the details of how the system will do it. In an object-oriented system, use cases are the system requirements. The diagrams in this view are: Use-case diagrams Sequence diagrams Collaboration diagrams Activity diagrams

    30. logical view It focuses on how the system will implement the behavior in the use cases. It includes the specific classes that will be needed, the Class diagrams, and the State chart diagrams. you can identify classes and packages that can be reused by grouping classes together. Once you've identified the classes and diagrammed them, you can move on to the Component view

    31. logical view The diagrams in this view are: Class diagrams State chart

    33. component view A component is a physical module of code (code libraries, executable files, run-time libraries) . It allows you to see the relationships between the modules of code. Developers will use the it to see what code libraries have been created and which classes are contained in each code library. .

    35. deployment view It concerned with the physical deployment of the system. It shows the processes and devices on the network and the physical connections between them. it shows which processes run on which machines. the primary users will be the staff responsible for distributing the application. This view contains only one diagram –the deployment diagram.

More Related