Published on


Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Introduction to UML Object Oriented Analysis & Design(OOAD) Lesson #1
  2. 2. Topics Covered <ul><li>Introduction to UML </li></ul><ul><li>UML Building Blocks </li></ul><ul><li>Rules of the UML </li></ul><ul><li>Common Mechanisms in the UML </li></ul><ul><li>Architecture </li></ul>
  3. 3. UML is a Language <ul><li>UML is a modeling language , a notation used to express and document designs. </li></ul><ul><li>(Language = Vocabulary + Grammar) </li></ul><ul><li>Language for communication. </li></ul><ul><li>UML unifies the notation of Booch, Rumbaugh (OMT) and Jacobson(OOSE). </li></ul><ul><li>UML proposes a standard for technical exchange of models and designs. </li></ul><ul><li>UML tells how to create and read well-formed models. </li></ul>
  4. 4. UML: a Language for Visualizing <ul><li>A picture will always be worth a thousand words! </li></ul><ul><li>Provides a description of the software that non programmers can understand (e. g. Use Case Diagrams). </li></ul><ul><li>Provides the facility to construct the model by constructing the model views. </li></ul><ul><li>Inter - relating diagrams provide a mechanism for detecting conflicts in the design and in user requirements. </li></ul><ul><li>UML is a graphical language </li></ul><ul><ul><li>Well-defined syntax </li></ul></ul><ul><ul><li>Well-understood semantics </li></ul></ul><ul><ul><ul><li>Interpretation or meaning of symbols. </li></ul></ul></ul>
  5. 5. UML: a Language for Specifying <ul><li>Build models that are </li></ul><ul><ul><li>Precise – clearly and accurately defined. </li></ul></ul><ul><ul><li>Unambiguous – allowing of only one interpretation. </li></ul></ul><ul><ul><li>Complete – capturing all relevant knowledge. </li></ul></ul><ul><li>Capture all important analysis, design and implementation issues in developing and deploying a software system. </li></ul>
  6. 6. UML: a Language for Constructing <ul><li>Possible to “map” from UML to a programming language. </li></ul><ul><li>Supports forward engineering from the method to an implementation. </li></ul><ul><li>Supports reverse engineering from implementation to its underlying model in UML. </li></ul><ul><li>Results in “round-trip” engineering – forward or backward. </li></ul><ul><li>Supports direct execution (simulation) of models. </li></ul>
  7. 7. UML: a Language for Documenting <ul><li>Artifacts in software development </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>Architecture </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Source code </li></ul></ul><ul><ul><li>Project plan </li></ul></ul><ul><ul><li>Tests </li></ul></ul><ul><ul><li>Prototypes </li></ul></ul><ul><ul><li>Releases </li></ul></ul><ul><ul><li>User manuals </li></ul></ul><ul><li>Artifacts are deliverables. </li></ul><ul><li>Artifacts also help control, measure, and communicate during system development. </li></ul>
  8. 8. UML is NOT <ul><li>UML is not a method or methodology. </li></ul><ul><ul><li>(Method = Notation (e.g.,UML) + Process) </li></ul></ul><ul><li>UML does not tell what models to use or what steps to use to create them. </li></ul>
  9. 9. Why use UML <ul><li>Standardized notation without sacrificing specialized model data. </li></ul><ul><li>Common language that can be used from product conception to delivery, from system to detailed design levels. </li></ul><ul><li>Reduced learning curve across projects. </li></ul><ul><li>Increased customer involvement /understanding of problem translation to product solution. </li></ul>
  10. 10. Motivation for UML
  11. 11. Motivation for UML (cont.) <ul><li>So…can model a system before construction </li></ul><ul><ul><li>Acts like blueprint for a large system </li></ul></ul>
  12. 12. The UML - Goals <ul><li>Provide a visual modeling language that is </li></ul><ul><ul><li>Ready to use </li></ul></ul><ul><ul><li>Expressive </li></ul></ul><ul><ul><li>Independent of particular programming language </li></ul></ul><ul><ul><li>Independent of development process </li></ul></ul><ul><ul><li>Extensible </li></ul></ul><ul><ul><ul><li>Core concepts can be extended or specialized by users </li></ul></ul></ul><ul><li>Supportive of high-level concepts </li></ul><ul><ul><li>E.g. collaborations, frameworks, patterns, components </li></ul></ul><ul><li>Provide modeling language that </li></ul><ul><ul><li>Integrate best practices </li></ul></ul><ul><ul><li>Encourages growth of OO tools market. </li></ul></ul>
  13. 13. Conceptual Model of the UML <ul><li>What makes up UML? </li></ul><ul><ul><li>UML uses THREE types of building blocks: </li></ul></ul>Things…first class citizens Relationships…tie things together Diagrams…group interesting collections of things
  14. 14. Things (Entities) <ul><li>There are four kinds of entities available: </li></ul><ul><ul><li>Structural things. </li></ul></ul><ul><ul><li>Behavioral things. </li></ul></ul><ul><ul><li>Collections/ Grouping things. </li></ul></ul><ul><ul><li>Annotational things. </li></ul></ul>
  15. 15. Structural Things <ul><li>The nouns of the UML models </li></ul><ul><li>These are mostly static parts of a model, representing elements that are either </li></ul><ul><ul><li>Conceptual or physical </li></ul></ul><ul><li>Seven types of structures </li></ul><ul><ul><li>Classes </li></ul></ul><ul><ul><li>Interfaces </li></ul></ul><ul><ul><li>Collaboration </li></ul></ul><ul><ul><li>Use Cases </li></ul></ul><ul><ul><li>Active Classes </li></ul></ul><ul><ul><li>Components </li></ul></ul><ul><ul><li>Nodes </li></ul></ul>
  16. 16. UML Structures: Class <ul><li>A UML class is a rectangle which contains the class name the class attributes and operations. </li></ul><ul><li>Graphical Notation: </li></ul>
  17. 17. UML Structures: Interface <ul><li>Represents the public or a collection of operations of a class or component. </li></ul><ul><li>May not show the complete set of public operations. </li></ul><ul><li>Is attached to the class or component that realises the interface. </li></ul><ul><li>The term realises is a mapping between the operations referred to in the interface and the class or component where they are actually implemented (see later). </li></ul><ul><li>Is represented by a circle and the interface name. </li></ul><ul><li>Graphical Notation: </li></ul>Stack Interface
  18. 18. UML Structures: Use Case <ul><li>Represents a coherent unit of functionality to be supported by the system. </li></ul><ul><li>Used to specify the intended behavior (the “what”) of a system </li></ul><ul><ul><li>Describe externally visible functionality </li></ul></ul><ul><ul><li>Identify high-level services provided by the system </li></ul></ul><ul><li>A description of a set of sequence of actions that a system performs for a particular actor. </li></ul><ul><li>An actor may be: </li></ul><ul><ul><li>A human (hopefully!) user </li></ul></ul><ul><ul><li>An external software system </li></ul></ul><ul><li>A Use Case is represented in UML as a title encapsulated in an ellipse and an Actor is represented as a stick figure. </li></ul><ul><li>Graphical Notation: </li></ul>Use Case
  19. 19. UML Structures: Collaboration <ul><li>Defines the classes and other software components required to implement a use case. </li></ul><ul><li>A Realisation is the mapping between a Use Case and its collaboration. </li></ul><ul><li>Represented in UML as a title encapsulated in a dashed line ellipse. </li></ul><ul><li>Graphical Notation: </li></ul>
  20. 20. UML Structures: Active Class <ul><li>A class whose objects own one or more processes or threads and therefore can initiate control activity. </li></ul><ul><li>Graphically an active class is rendered just like a class, but with heavy lines. </li></ul><ul><li>Graphical Notation: </li></ul>
  21. 21. UML Structures: Component <ul><li>A component under UML has a similar meaning as a software component: A replaceable part of the software system that implements one or more interfaces. </li></ul><ul><li>Under UML a component is represented as a title encapsulated by a rectangle with tabs. </li></ul><ul><li>Graphical Notation: </li></ul>Registration.exe
  22. 22. UML Structures: Node <ul><li>An element that exists at run time and represents a computational resource, generally having at least some memory and, often processing capability. </li></ul><ul><li>Represented in UML as 3D cube labeled with the device’s name. </li></ul><ul><li>Graphical Notation: </li></ul>
  23. 23. Behavioral Things <ul><li>Verbs of a model, representing behavior over time and space. </li></ul><ul><ul><li>Generally connected to classes, collaboration and objects. </li></ul></ul><ul><li>Behavioral things are: </li></ul><ul><ul><li>Interactions, and </li></ul></ul><ul><ul><li>State machines </li></ul></ul>
  24. 24. Behavioral Things: Interaction <ul><li>Set of messages exchanged among objects within a context to accomplish a purpose. </li></ul><ul><li>An interaction is composed of: </li></ul><ul><ul><li>The set of messages. </li></ul></ul><ul><ul><li>Action sequences (caused by invoking a message). </li></ul></ul><ul><ul><li>Links or connections between objects (relationships between objects). </li></ul></ul><ul><ul><li>(Interaction = Messages +Action Sequences + Links) </li></ul></ul><ul><ul><li>Points to object that receives the message </li></ul></ul><ul><li>Graphical Notation: </li></ul>
  25. 25. Behavioral Things: State Machine <ul><li>Represents a sequences of states connected by transitions, which together describe the life cycle of a single object or set of objects. </li></ul><ul><ul><li>(State Machine = States + Transitions + Events + Activities) </li></ul></ul><ul><li>State is shown as rounded rectangle. </li></ul><ul><li>Graphical Notation: </li></ul>Waiting
  26. 26. Grouping (Collection) Things <ul><li>Things into which you can </li></ul><ul><ul><li>Decompose a model, or </li></ul></ul><ul><ul><li>With which you can combine model elements. </li></ul></ul><ul><li>Grouping thing: </li></ul><ul><ul><li>Package </li></ul></ul>
  27. 27. Grouping (Collection) Things: Package <ul><li>Collection entities are a mechanism for subdividing the software model into smaller sub - models. </li></ul><ul><li>These sub - models are known as package s. Unlike components, packages exist only in the design. The implementation of the design will not (necessarily) contain packages. </li></ul><ul><li>Under UML, collection entities are represented as a tabbed box containing the title of the package. </li></ul><ul><li>Graphical Notation: </li></ul>User Forms
  28. 28. Annotational Things <ul><li>Comments to describe, illuminate, or remark about any element in a model. </li></ul><ul><li>Annotational thing: </li></ul><ul><ul><li>Note </li></ul></ul>
  29. 29. Annotational Things : Note <ul><li>An annotation can be attached to any element in a software model. </li></ul><ul><li>Used for informal or formal text </li></ul><ul><li>Using a CASE tool an annotation will be a link to a text file or word processor document. </li></ul><ul><li>Under UML an annotation is represented by a box with a folded corner, containing the title of the annotation. </li></ul><ul><li>Graphical Notation: </li></ul>
  30. 30. Relationships <ul><li>Objects contribute to the behavior of a system by collaborating with one another. </li></ul><ul><li>Collaboration is accomplished through relationships. </li></ul><ul><li>There are four kinds of entities available: </li></ul><ul><ul><li>Dependency </li></ul></ul><ul><ul><li>Association </li></ul></ul><ul><ul><li>Generalization </li></ul></ul><ul><ul><li>Realization </li></ul></ul>
  31. 31. Relationships: Dependency <ul><li>Semantic relationship between two things such that a change in one thing (the “independent” thing) may affect the semantics of another thing (the “dependent” thing). </li></ul><ul><li>May have direction, may have a label. </li></ul><ul><li>Dependency means one thing “uses” another. </li></ul><ul><li>Graphical Notation: </li></ul>
  32. 32. Relationships: Association <ul><li>Structural relationship that describes a set of links; I.e.relationships between objects. </li></ul><ul><li>May have direction, may include a label, and often containing adornments such as multiplicity and role names. </li></ul><ul><li>Graphical notation: </li></ul>
  33. 33. Relationships: Generalization <ul><li>It is a relationship between a super-class and a child class. </li></ul><ul><li>A child is substitutable for a parent. </li></ul><ul><li>Child shares the structure and behavior of parent. </li></ul><ul><li>Graphical Notation: </li></ul>
  34. 34. Relationships: Realization <ul><li>One element specifies a “contract” that another element must carry out. </li></ul><ul><ul><li>Open headed arrow points from the “realizer” to the element with the contract. </li></ul></ul><ul><li>The element carrying out the “contract” is said to realize the other element. </li></ul><ul><li>Graphical Notation: </li></ul>
  35. 35. Diagrams: An Overview <ul><li>Diagram is a collection of elements and their relationships. </li></ul><ul><li>Diagram is a projection (“shadow”) into a system </li></ul><ul><li>Kinds of Diagrams: </li></ul><ul><ul><li>Use Case Diagrams </li></ul></ul><ul><ul><li>Class Diagrams </li></ul></ul><ul><ul><li>Object Diagrams </li></ul></ul><ul><ul><li>Interaction Diagrams </li></ul></ul><ul><ul><ul><li>Sequence Diagrams </li></ul></ul></ul><ul><ul><ul><li>Collaboration Diagrams </li></ul></ul></ul><ul><ul><li>State Diagrams </li></ul></ul><ul><ul><li>Activity Diagrams </li></ul></ul><ul><ul><li>Component Diagrams </li></ul></ul><ul><ul><li>Deployment Diagrams </li></ul></ul>
  36. 36. Use Case Diagram <ul><li>Shows actors, use cases and their relationships. </li></ul><ul><li>Can be used to provide an overview of </li></ul><ul><ul><li>The functionality to be supported by the system </li></ul></ul><ul><ul><li>The actors interacting with the system </li></ul></ul><ul><ul><li>Relationships between actors and use cases </li></ul></ul><ul><li>Addresses the visible behaviors of a system. </li></ul>
  37. 37. Class Diagram <ul><li>Shows the relationships between: </li></ul><ul><ul><li>classes </li></ul></ul><ul><ul><li>interfaces </li></ul></ul><ul><ul><li>collaborations. </li></ul></ul><ul><li>Easiest to understand and most commonly used. </li></ul><ul><li>Class diagrams are a static view of the system being designed. </li></ul>
  38. 38. Object Diagram <ul><li>A class diagram describes classes and class relationships. An object diagram shows objects and associations between objects. </li></ul><ul><li>It is a static snapshot of the system but from an implementation perspective. </li></ul><ul><li>Each class will only appear once in a class diagram. </li></ul><ul><li>In an object diagram each object will only appear once but many of the objects could be instances of the same class. </li></ul><ul><li>A class diagram shows class hierarchies. </li></ul><ul><li>An object diagram shows connections between objects. </li></ul>
  39. 39. Interaction (Event Trace) Diagram <ul><li>Two kinds: </li></ul><ul><ul><li>Sequence diagrams, and </li></ul></ul><ul><ul><li>Collaboration diagrams </li></ul></ul><ul><li>Addresses the dynamic view of a system. </li></ul><ul><li>Using Rational Rose it is possible to generate one from the other. </li></ul>
  40. 40. Interaction Diagram: Sequence Diagram <ul><li>Addresses time-ordering of messages : message centered. </li></ul><ul><li>Time sequence is easier to see in the sequence diagram, read from top to bottom. </li></ul><ul><li>Choose sequence diagram when only the sequence of operations needs to be shown </li></ul>: Student registration form registration manager math 101 1: fill in info 2: submit 3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe) 7: add (joe) math 101 section 1
  41. 41. Interaction Diagram: Collaboration Diagram <ul><li>Addresses organization of objects that send and receive : object centered. </li></ul><ul><li>Time sequence is shown by numbering the message label of the links between objects. </li></ul><ul><li>Choose collaboration diagram when the objects and their links facilitate understanding the interaction, and sequence of time is not as important. </li></ul>: Registrar course form : CourseForm theManager : CurriculumManager aCourse : Course 1: set course info 2: process 3: add course 4: new course
  42. 42. State Diagram <ul><li>Show all the possible states that objects of the class can have and which events cause them to change. </li></ul><ul><li>Show how the object’s state changes as a result of events that are handled by the object. </li></ul><ul><li>Good to use when a class has complex lifecycle behavior. </li></ul><ul><li>Addresses event-ordered behavior of objects. </li></ul>
  43. 43. Activity Diagram <ul><li>Show the sequential flow of activities. </li></ul><ul><li>A combination of activities and event flows. </li></ul><ul><li>Used to show the flow from one activity to the next. </li></ul><ul><li>Encourage discovery of parallel processes which helps eliminate unnecessary sequences in business processes. </li></ul><ul><li>Addresses dynamic view of a system. </li></ul>
  44. 44. Component Diagram <ul><li>Component diagrams illustrate the organizations and dependencies among software components (the physical world) </li></ul><ul><li>A component may be </li></ul><ul><ul><li>A source code component </li></ul></ul><ul><ul><li>A run time components or </li></ul></ul><ul><ul><li>An executable component </li></ul></ul><ul><li>Addresses implementation view of the system. </li></ul>CourseInfo PeopleInfo Course CourseOffering StudentInfo ProfessorInfo Register.exe
  45. 45. Deployment Diagram <ul><li>Shows run-time processing nodes – system architecture. </li></ul><ul><li>Highlight the physical relationships among software and hardware components in the delivered system. </li></ul>Registration Database Library Dorm Main Building
  46. 46. Rules of the UML <ul><li>The UML's building blocks can't simply be thrown together in a random fashion. </li></ul><ul><li>Like any language, the UML has a number of rules that specify what a well-formed model should look like. </li></ul><ul><li>Semantic rules for a well-formed model </li></ul><ul><li>Names : What you can call things , relationships , and diagrams </li></ul><ul><li>Scope : The context that gives specific meaning to a name </li></ul><ul><li>Visibility : How those names can be seen and used by others </li></ul><ul><li>Integrity : How things properly and consistently relate to one another </li></ul><ul><li>Execution : What it means to run or simulate a dynamic model </li></ul>
  47. 47. Rules of the UML (cont.) <ul><li>During development, we can build models that are: </li></ul><ul><ul><li>Elided: Certain elements are hidden to simplify the view </li></ul></ul><ul><ul><li>Incomplete: Certain elements may be missing </li></ul></ul><ul><ul><li>Inconsistent: The integrity of the model is not guaranteed </li></ul></ul><ul><li>These are all necessary if we are to use the models to develop understanding </li></ul><ul><li>Rules encourage – but do not force – addressing all the important aspects of modeling a system over time. </li></ul>
  48. 48. Common Mechanisms in the UML <ul><li>A building can be made simpler…by using certain architectural patterns !!! </li></ul><ul><li>The same is true of the UML. </li></ul><ul><ul><li>It is made simpler by the presence of FOUR mechanisms: </li></ul></ul><ul><ul><ul><li>Specifications </li></ul></ul></ul><ul><ul><ul><li>Adornments </li></ul></ul></ul><ul><ul><ul><li>Common divisions </li></ul></ul></ul><ul><ul><ul><li>Extensibility mechanisms </li></ul></ul></ul>
  49. 49. Specifications <ul><li>UML is more than a graphical notation. </li></ul><ul><ul><li>Every part of the graphical notation there is a specification that provides a textual statement of the the syntax and semantics of that building block. </li></ul></ul><ul><ul><li>Example : </li></ul></ul><ul><ul><ul><li>Class icon might only show a small part of specifications. </li></ul></ul></ul><ul><ul><ul><li>Specification provides a full a set of attributes, operations, full signatures and behaviors. </li></ul></ul></ul><ul><ul><li>UML graphical notation to to visualize a system. </li></ul></ul><ul><ul><li>UML’s specifications to state the system’s details. </li></ul></ul>
  50. 50. Adornments <ul><li>Optional details rendered as graphic or text. </li></ul><ul><ul><li>Example: Transaction is an abstract class, with two public, one protected and one private operation. </li></ul></ul>
  51. 51. Common Divisions <ul><li>In modeling object-oriented systems, the world gets divided in at least a couple of ways. </li></ul><ul><li>Abstraction vs. manifestation </li></ul><ul><ul><li>Intention vs. extension </li></ul></ul><ul><ul><li>&quot;Class&quot; vs. &quot;object&quot; </li></ul></ul><ul><ul><ul><li>Class is an abstraction </li></ul></ul></ul><ul><ul><ul><li>Object is a concrete manifestation of that abstraction </li></ul></ul></ul><ul><ul><li>Example: </li></ul></ul><ul><ul><ul><li>Customer is an abstraction, </li></ul></ul></ul><ul><ul><ul><li>Jan is a particular customer, </li></ul></ul></ul><ul><ul><ul><li>there is an (un-named) instance of customer and </li></ul></ul></ul><ul><ul><ul><li>Elyse is a real thing (object). </li></ul></ul></ul>Most UML building blocks have this kind of “class / object” distinction; e.g., use case, use case instance, etc.
  52. 52. More Divisions <ul><li>Interface vs. implementation </li></ul><ul><ul><li>Interface declares a &quot;contract” or agreement </li></ul></ul><ul><ul><li>Implementation represents one concrete realization of that contract, responsible for carrying out the interface. </li></ul></ul>Example: spellingwizard realizes the Iunknown and Ispelling interfaces
  53. 53. Extensibility mechanisms <ul><li>UML provides a standard language for writing software; </li></ul><ul><ul><li>But… it is not possible for one closed language to be sufficient to express all fine distinction in the models. </li></ul></ul><ul><ul><li>So…UML is making possible to extend the language. </li></ul></ul><ul><ul><li>Stereotypes: </li></ul></ul><ul><ul><ul><li>Allows to create new kinds of building blocks that are derived from existing ones. </li></ul></ul></ul><ul><ul><li>Tagged values: </li></ul></ul><ul><ul><ul><li>Allows to create new information in the elements specifications. </li></ul></ul></ul><ul><ul><li>Constraints: </li></ul></ul><ul><ul><ul><li>Allows to add new rules or modify existing ones. </li></ul></ul></ul>
  54. 54. Extensibility Mechanisms - Stereotypes <ul><li>Stereotypes allow the controlled extension of metamodel classes by UML users. </li></ul><ul><li>Graphically rendered as </li></ul><ul><ul><li>Name enclosed in guillemets ( << >> ) </li></ul></ul><ul><ul><ul><li><<stereotype>> </li></ul></ul></ul><ul><ul><ul><li>E.g., « metaclass » </li></ul></ul></ul><ul><ul><li>New icon (use color to accentuate) </li></ul></ul>« metaclass » ModelElement Internet <ul><li>The new building block can have </li></ul><ul><ul><li>its own special properties through a set of tagged values </li></ul></ul><ul><ul><li>its own semantics through constraints </li></ul></ul>
  55. 55. Extensibility Mechanisms - Tagged Values <ul><li>A tagged value is a (name, value) pair that describes a property of a model element. </li></ul><ul><li>Properties allow the extension of metamodel element attributes . </li></ul><ul><li>A tagged value modifies the semantics of the element to which it relates. </li></ul><ul><li>Rendered as a text string enclosed in braces { } </li></ul><ul><li>Placed below the name of another element. </li></ul>Server {channels = 3} <<library>> accounts.dll {customerOnly} tagged values « subsystem » AccountsPayable { dueDate = 12/30/2002 status = unpaid }
  56. 56. Extensibility Mechanisms - Constraints Portfolio BankAccount {secure} A simple constraint <ul><li>Extension of the semantics of a UML element. </li></ul><ul><li>Allows new or modified rules, i.e., conditions that must hold true. </li></ul><ul><li>Rendered in braces {} . </li></ul><ul><ul><li>Informally as free-form text, or </li></ul></ul><ul><ul><li>Formally in UML’s Object Constraint Language (OCL): </li></ul></ul><ul><ul><li>E.g., {self.wife.gender = female and self.husband.gender = male} </li></ul></ul><ul><ul><li>Can be contained also in a note. </li></ul></ul>Constraint across multiple elements Corporation BankAccount {or} Person id : {SSN, passport} Department Person * * 1..* 1 member manager {subset}
  57. 57. Standard Extensibility Elements <ul><li>UML User’s Guide—Appendix B </li></ul><ul><li>Standard stereotype for tool builders </li></ul><ul><ul><li>Stereotype — specifies that the classifier is a stereotype that may be applied to other elements. </li></ul></ul><ul><li>Standard tagged value </li></ul><ul><ul><li>Documentation — specifies a comment, description, or explanation of the element to which it is attached. </li></ul></ul>
  58. 58. Representing Architecture <ul><li>The need for viewing complex systems from different perspectives. </li></ul><ul><ul><li>Such as; </li></ul></ul><ul><ul><ul><li>End users, analysts, developers, project managers…etc. will look at the system in different ways at different times. </li></ul></ul></ul><ul><ul><li>A system architecture can be used to manage these different viewpoints. </li></ul></ul><ul><ul><li>Architecture is the set of significant decisions about; </li></ul></ul><ul><ul><ul><li>Organization of a software system </li></ul></ul></ul><ul><ul><ul><li>Structural elements and interfaces </li></ul></ul></ul><ul><ul><ul><li>Behavior of collaborations among elements </li></ul></ul></ul><ul><ul><ul><li>Composition of elements into larger subsystems </li></ul></ul></ul><ul><ul><ul><li>Architectural style </li></ul></ul></ul><ul><ul><ul><li>Different stakeholders have different views </li></ul></ul></ul>
  59. 59. Views of Architecture
  60. 60. <ul><li>Use case view - system as seen by end users </li></ul><ul><ul><li>Reflected in other models and views </li></ul></ul><ul><li>Design view - classes, interfaces, collaborations that constitute vocabulary of the problem and its solution </li></ul><ul><li>Process view - threads and processes </li></ul><ul><ul><li>Focus on active classes </li></ul></ul><ul><li>Implementation view - components and files to assemble and release the physical system </li></ul><ul><li>Deployment view - nodes that form system hardware topology </li></ul>Views of Architecture (Cont.)
  61. 61. Summary <ul><li>UML is a modeling language, a notation used to express and document designs. </li></ul><ul><li>Building blocks of the UML </li></ul><ul><ul><li>Things </li></ul></ul><ul><ul><li>Relationships </li></ul></ul><ul><ul><li>Diagrams </li></ul></ul><ul><li>UML Rules encourage – but do not force !!! </li></ul><ul><li>Common Mechanisms in the UML </li></ul><ul><ul><ul><li>Specifications </li></ul></ul></ul><ul><ul><ul><li>Adornments </li></ul></ul></ul><ul><ul><ul><li>Common divisions </li></ul></ul></ul><ul><ul><ul><li>Extensibility mechanisms </li></ul></ul></ul><ul><li>UML system architecture can be used to manage these different viewpoints. </li></ul>
  62. 62. Thanks folks