Published on

Published in: Technology, Education
1 Like
  • 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. Architectural UML Paolo Ciancarini
  2. 2. Agenda•  Models and software architecture•  Architectural views•  Extending UML: profiles•  Changing UML: metamodels
  3. 3. Software Architecture•  The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems•  Hundreds of definitions on CMU page:!
  4. 4. 1471 simplified identifies Stakeholder Architectural concerns 1..* description selectsaddressed by consists of 1..* 1..* conforms to 1..* Viewpoint 1 View consists of establishes methods for 1..* 1..* Model
  5. 5. DiscussWhat are the elements of a software architecture?What are the main operations on an architecture?How can we decide that a system model is conform to an architecture (or to an architectural style)?
  6. 6. Architectural views and concerns
  7. 7. Architectural views
  8. 8. Different views <<concept>> <<concept>>Conceptual Order UrgentOrdermodel deliveryCharge: Money <<dynamic>> <<type>> OrderSpecification deliveryCharge: Moneymodel isUrgent: Boolean beUrgent() <<class>> DeliveryStrategy 1 getCharge(): Money <<class>> OrderImplementationmodel getDeliveryCharge(): Money isUrgent(): Boolean <<class>> <<class>> RegularDelivery UrgentDelivery beUrgent() getCharge(): Money getCharge(): Money
  9. 9. How it all fitstogether
  10. 10. Models and diagrams
  11. 11. Architectural description languages•  ADL: Overloaded acronym I.  The enterprise modeling meaning II.  The system engineering meaning III.  The software engineering meaning•  Examples I.  Archimate II.  SysML (UML profile for System Engineering) III.  ACME, Darwin, Wright
  12. 12. Archimate framework
  13. 13. Archimate example
  14. 14. UML as an architectural language•  UML 1.* was based mostly on Classes and Objects –  Behavioral diagrams were not well linked to structure•  UML 2.* models enterprises and architectures in a much more expressive and refined way –  Structural Models – Behavioral Models –  Architectural Models – Deployment Models•  UML 2.* is a powerful notational technology: –  Static and dynamic modeling elements include internal structure, components, ports, behavioral features –  Behavioral diagrams all derive from a common behavioral model –  All features are designed to scale to large systems –  The new capabilities serve methodologists, enterprise modelers, language designers, and tool builders
  15. 15.
  16. 16. Models and views•  UML is a language to describe systems; its main concepts are models and views•  A view is a perspective on the system by some stakeholder; it is made of a number of different diagrams, grouped in one ore more models•  A model is a container of three things: classifiers, events, and behaviors; each of them represents individuals in some view of the system being modeled
  17. 17. UML Models•  A model contains classifiers, events, and behaviors –  A classifier describes a set of objects; an object is an individual thing with a state and relationships to other objects –  An event describes a set of possible occurrences; an occurrence is something that happens that has some consequence within the system –  A behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules•  UML models do not contain objects, occurrences, and executions, because those things are the subject of models, not their content
  18. 18. Example: a model for chess chessboardplayer position piece K Q R B N P
  19. 19. Views on the chess model•  Player view •  Architectural view?•  Designer view •  Standard view?•  Tester view •  Platform view?•  Coder view •  Cost view?•  Deployer view •  Service view?•  Maintenance view •  Metamodeling view?
  20. 20. Metamodeling (or conformance) view conformsTo Chess Game 2 * *player chessboard Agent board 32 * chesspieces pieces
  21. 21. (4+1) Architectural View ModelI.  Design (or logical) View: shows the structural view of a system. This gives an idea of what a given system is made up of. Class, object, communication, sequence diagrams form this viewII.  Process View: shows the dynamic behavior of a system. The state, activity, sequence, and collaboration diagrams are used in this viewIII.  Development (or implementation) View: shows the modules of a given system and their dependencies modeled using the package and component diagramsIV.  Physical (or deployment) View: is used to identify the deployment modules for a given system•  Scenario (or Use case) View: Use case diagrams are used to view a system as a set of functions, distinct activities or transactions
  22. 22. Architecture & 4+1 ViewsArchitecture - set of significant decisions concerning:   Organization of a software system   Selection of structural elements & interfaces from which a system is composed   Behavior or collaboration of elements   Composition of structural and behavioral elements   Architectural style guiding the system vocabulary system assembly functionality Design View Implementation View configuration mgmt. behavior Use Case View system topology performance distribution scalability Process View Deployment View delivery throughput installation
  23. 23. Use Case View Logical View Physical View Deployment V.Focus Expression of Expressing Representing Implementing Deployment of requirements Behavior Structure Objects and Classes Executable Code use case statechart class diagrams diagrams diagrams componentDiagram object diagrams sequence deployment diagrams diagrams diagrams collaboration activity diagrams diagrams Actors Objects Modules Nodes Use cases Classes Subroutines ModulesElement Classes Collaborations Tasks Main Programs Collaborations Interactions Subsystems Categories UML diagrams model a system from different perspectives
  24. 24. Use case view•  Use Case Analysis is a technique to capture a set of functional requirements or a business process from some stakeholder’s perspective•  The use case view encompasses the system behavior as seen by users, analysts, and testers•  It specifies the forces that shape the architecture•  The static aspects are depicted in use case diagrams; the dynamic aspects in sequence and activity diagrams
  25. 25. Design view•  The design view encompasses classes, interfaces, and collaborations that define the vocabulary of a system•  It supports the main data structures and the functional requirements of the system•  Static aspects in class and object diagrams, sometimes some packages are added; dynamic aspects in interaction diagrams, especially sequence diagrams
  26. 26. Implementation View•  The implementation view encompasses the sources, components, and files used to compile, assemble, and release a physical system•  It addresses configuration management•  Static aspects in package diagrams, including dependency relationships; runtime issues and interfaces in component diagrams
  27. 27. Process view•  The process view encompasses the threads and processes defining concurrency and synchronization inside an implemented system•  It addresses non functional requirements like performance, scalability, and throughput•  Static aspects captured as in design view but also with component diagrams; dynamic issues in activity diagrams
  28. 28. Deployment view•  The deployment view encompasses the nodes that form the system hardware topology•  It addresses the distribution, delivery, and installation of a software product•  Static aspects in deployment diagrams; dynamic aspects in interaction diagrams
  29. 29. Architectural Modeling in UMLLogical View Implementation View id Business Entity (Client)cd Users «Include» Business Entities::Employee dsXxx.i + Address: CHARACTER includes - DEFINE DATASET <dataset-def>: + City: CHARACTER + email: CHARACTER includes - EmployeeLanguage: CHARACTER Architecture Entities::User + employmentEndDate: DATETIME-TZ + employmentStartDate: DATE - UserEmail: CHARACTER + FirstName: CHARACTER «Program» Architecture Entities:: «include» - UserLogin: CHARACTER 1 1 + LastName: CHARACTER Language «includes» ClientXxx.p «includes» «Include» - UserPassword: CHARACTER + MobilePhoneNumber: CHARACTER ttContext.i etXxx.i + Notes: CHARACTER 1 - Description: CHARACTER Use Case View 0..* + PhoneNumber: CHARACTER - Language: CHARACTER includes 0..* + Position: CHARACTER + PostCode: CHARACTER + createEmployee() : void + deleteEmployee() : void «Include» + findEmployee() : void proSIproxyStart.i 1 + isAvailable() : LOGICAL + updateEmployee() : void ud Manage Employees - NEW GLOBAL SHARED VARIABLE ghProxySIproc: Architecture Entities::UserGroups + validateEmployee() : void - UserGroupDescription: CHARACTER AutoEdge System «realize PERSISTENT» - UserGroupName: CHARACTER Brow se Employees «Program» proSIproxy.p - NEW GLOBAL SHARED VARIABLE ghttProxySIproc: HANDLE «use» + fetchWhere(CHARACTER, HANDLE, DATASET-HANDLE*) : void Delete Employee + saveChanges(CHARACTER, HANDLE, CHARACTER*) : void «use»Dynamic View Deployment View Update Employee Manager (from Actors) «include» sd Login Create Employee Create User «extend» Client Server Gateway Security Session Context dd Integration Request("Security", "Login", ...) HQ System isValidUser(Login, password) ValidUser Sonic [if Valid User]: createSession Sonic Sonic Sonic Sonic sessionID Dealer Dealer Dealer Dealer System 1 System 2 System 3 System n [if valid user]: sessionID (from Architecture Components) (from Architecture Components) (from Architecture Components) Architecture Components) (from Philippe Krutchen
  30. 30. Architectural analysis and design•  Architectural analysis involves organizing analysis classes into packages –  Use cases –  Analysis classes –  Use case realisations•  Architectural design involves refining the model elements of a package –  Design classes –  State machine diagrams –  Deployment diagrams
  31. 31. Architectural View Veterans’ City Medic Hospital Fire Dept AlertVPN City Internet Friendly Hospital HMO Patriot Acme Dr. Jones’ Ambulance Home Care Office
  32. 32. Zoomed, Still ArchitecturalVeterans’ Hospital MedicAlert® Patient Customer Database Database Internet Emergency Web Room App Interface Radiology Telecomms Dept App Folks’ App
  33. 33. Enterprise Architecture View Veterans’ Hospital Internal Connectivity Patient Emergency Detail Database Room App Suppressed Server Radiology ER’s Dept App Patient DB Firewall Radiology’s Pharmacy Patient DB Database Admitting Admitting’s Internet Dept App Database Billing Accounting Dept App App & DB
  34. 34. Application Model Emergency Room AppTriage Component ER Patient DB ER’s Access Component Firewall ER Billing Component
  35. 35. Component Model Triage Component Then MDA Generates Triage Class 1 the application Triage Class 1 and its connectivity Attributes from this detailed model Triage Class 1 Operations So you know that the applicationTriage Operations conforms to the Behaviors model, connectivity works, and changes to Triage Class 2 any level model work in the real world
  36. 36. Static vs. dynamic models•  Static model –  Describes the static structure of a system –  Consists of a set of objects (classes) and their relationships –  Represented as class diagrams•  Dynamic model –  Describes the dynamic behavior of a system, such as its state transitions and interactions (message sends) –  Represented as statechart, activity, sequence, and communication diagrams
  37. 37. Relationships among diagrams
  38. 38. Packages and components•  Packages organize model elements, but have no realisation in the modeled system•  A package primarily provides a namespace•  Component diagrams describe black-box (emphasizing interfaces) or white box (emphasizing internal functions) model architectures
  39. 39. Models, Views, and DiagramsA model is a complete Static viewsdescription of a systemfrom a particularperspective Models Component DiagramsInteractions Dynamic views
  40. 40. A package modeling a viewA model captures a view of a system, with a certainpurpose. It is a complete description of thoseaspects of the system relevant to the purpose of themodel, at the appropriate level of detail
  41. 41. Models are documented by diagrams Diagrams make up the Use Case documentation of a model Model Design ModelRemark: models are seldom shown indiagrams
  42. 42. Example: analysis and design views Use Case Model Analysis Model Component Diagrams Incl. subsystem e package Design Model Depl. Model Impl. Model Test Model
  43. 43. Example: deployment and implementation models Use Case Model Analysis Model Component Diagrams Design Model Include classi e componenti attivi Depl. Model Impl. Model Test Model
  44. 44. Discuss•  Which diagrams are most important for a testing model?
  45. 45. Example: Test model Use Case Model Analysis Model Component Diagrams Design Model The testing model Depl. refers to all other Model models and uses their diagrams Impl. Model Test Model
  46. 46. Containment in models•  Two equivalent ways to show containment:
  47. 47. Hierarchies of modelsModels and subsystems (components) can be combined in hierarchies
  48. 48. Core ConceptsConstruct Description SyntaxModel A view of a system, with a certain purpose determining what aspects Name of the system are described and at what level of detailTrace A dependency connecting model «trace» elements that represent the same concept within different models. Traces are usually non-directed
  49. 49. TraceAnalysis Design «trace»
  50. 50. The use of models•  To give different views of a system to different stakeholders•  To focus on a certain aspect of a system at a time•  To express the results of different stages in a software development process•  To describe other models (eg metamodeling)
  51. 51. 4+1 architectural metamodel Architectural description selects consists of 1..4 validates 1..* View 1..* Use CaseLogical Implementation Process Deployment View View View View
  52. 52. Boocharchitectural metamodel
  53. 53. Architectural modeling with UML•  Motivations –  Accessibility –  Use of UML tools –  Compatibility with design models –  Standardization•  An architectural model encompasses different views: logical, dynamic, deployment•  All UML diagrams can be useful to describe aspects of an architectural model•  Some UML diagrams are particularly effective for architectural modeling: –  Package diagrams –  Component diagrams –  Deployment diagrams
  54. 54. Modeling software architectures in UML: structural aspects•  Using basic modeling elements –  Classes –  Objects –  Packages –  Components•  Using special UML extensions –  Built-in –  Custom
  55. 55. Architectural diagrams
  56. 56. UML for sw architectures•  UML is a well known industrial standard•  However, it has not been invented for depicting architectures, so it may need additional features•  UML can be extended –  Exploiting the built-in extension mechanisms –  Changing its metamodel
  57. 57. Extensions to model architectures•  Strategy 1: use UML “as it is”•  Strategy 2: use UML built-in extension mechanisms –  Eg. UML architectural profile •  Select meta-class semantically close to architectural abstractions •  Define a stereotype and apply it to metaclass instances •  Define and use specific architecttural style composition rules•  Strategy 3: extend the UML metamodel –  Eg. Exploit a model driven approach
  58. 58. Strategy 1: “plain” UML•  Analysis of architectural requirements•  Develop a UML model•  Develop an informal architectural diagram•  Map domain classes to architectural components•  Design component interfaces•  Model connectors•  Model architectures using class, object and communication diagrams
  59. 59. Example
  60. 60. A generic architecture (packages) interface User interface System interface function model technical platform ui-system dbms network
  61. 61. Strategy 2: Extending UMLDefine a profile!•  Exploit existing constructs –  Eg. component, connector, subsystem, etc.•  Define stereotypes for new constructs to model structural aspects of architectures•  Describe the behavioral semantics of the new constructs using OCL and dynamic diagrams
  62. 62. Strategy 2: Profiles•  A profile is a generic extension mechanism for customizing UML models for particular domains and platforms•  Profiles are defined using stereotypes, tagged values, and constraints•  A profile is a collection of such extensions that customizes UML for a particular domain (eg. aerospace, healthcare, financial) or platform (eg. J2EE, .NET)
  63. 63. Example
  64. 64. “Architectural” packageUML diagram <<metaclass>> <<metaclass>> Component ConnectorPipes&filters <<stereotype>> <<stereotype>> Filter Pipe 64
  65. 65. Component diagram<<pipe>><<pipe>> <<pipe>><<pipe>> <<pipe>> <<pipe>> <<pipe>><<pipe>><<filter>> <<filter>> <<filter>> <<filter>><<component>> <<component>> <<component>> <<component>>pic eqn tbl troff 65
  66. 66. A profile for board games
  67. 67. A testing profile
  68. 68. Some important profiles•  CORBA•  EDOC (profiles for Java and EJB)•  MARTE (Modeling and Analysis of Real-Time and Embedded Systems)•  SysML (profile for system engineering with UML)•  RUP profile for Business Modeling•  SOAML (UML profile for SOA)•  UPDM Unified Profile for DoDaf/MoDaf www.updm.comSome profiles are “officially” endorsed by OMGSee the list of OMG profiles in
  69. 69. A profile for EJB
  70. 70. A profile for
  71. 71. OMG Service Oriented Architecture•  Participants provide and use service contracts via ports•  Participants can “play roles” in multiple services architectures, defining their external requirements•  Each service contract they are bound to must interact through a compatible port•  Participants are the types of “participant roles” in the services architecture
  72. 72. Strategy 3Change the metamodel!•  Add to the metamodel new architectural constructs and constraints•  Define their architectural semantics•  Then follow an approach similar –  to Strategy 1 to model architectures –  to Strategy 2 to model architectural styles
  73. 73. Example: model and metamodel Vehicle Car Tire 1 4
  74. 74. From objects to models Superclass MetamodelinheritsFrom conformsTo Class ModelinstanceOf representedBy Instance System
  75. 75. The UML metamodel•  The UML infrastructure describes the UML metamodel•  OMG defined MOF (Meta Object Facility), a standard technology for defining metamodels•  The MOF has been primarily used for the UML metamodel, but it is also the basis for Model Driven Engineering
  76. 76. UML MetaModel (Partial)
  77. 77. Classmetamodel
  78. 78. Summary•  Profiles can capture either domain knowledge or architectural knowledge: they extend the metamodel•  UML is defined by a metamodel, that is it is defined using UML itself•  In UML2.0 the metamodel is called “the infrastructure”•  The metamodel includes the definitions for views, diagrams, and modeling elements•  UML can be extended to support architectures via profiles (avoiding to change the metamodel)•  When based on metamodeling, architectural specification can exploit “Model-driven Architecting”
  79. 79. Exercise•  Define a profile for a domain you know, eg for soccer, for music, for a computer or an operating system
  80. 80. Self test questions•  What is a model in UML?•  What is a profile?•  What is a metamodel?•  Using UML, how can we deal with architectural issues?
  81. 81. References•  OMG, UML Infrastructure 2.3, 2010•  Cheesman & Daniels, UML Components A Simple Process for Specifying Component-Based Software, Addison Wesley, 2000•  Garland & Anthony, Large-Scale Software Architecture. A Practical Guide using UML, Wiley 2003•  Altunbay and others, Model Driven Development of Board Games, TMODELS, 2009•  Cabot and Gomez, A simple yet useful approach to implementing UML Profiles in current CASE tools, 2003
  82. 82. Useful sites•!•!•!•!•!•!•!•!
  83. 83. Tools for architectural UML•!•!•!•!•!•!•!•!
  84. 84. Questions?