1 / 30

Architectural Modeling Notations

Architectural Modeling Notations. Objectives. To present several notations for architectural modeling Box-and-line diagrams UML package diagrams UML component diagrams UML deployment diagrams To present UML common notations Notes Constraints Properties Stereotypes. Topics.

marlow
Télécharger la présentation

Architectural Modeling Notations

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. Architectural Modeling Notations

  2. Objectives • To present several notations for architectural modeling • Box-and-line diagrams • UML package diagrams • UML component diagrams • UML deployment diagrams • To present UML common notations • Notes • Constraints • Properties • Stereotypes

  3. Topics • Box-and-line diagrams • UML common notations • Packages and package diagrams • Components and component diagrams • Nodes, artifacts, and deployment diagrams

  4. Box-and-Line Diagrams • Icons (boxes) connected with lines • No rules governing formation • Used for both static and dynamic modeling • Good idea to include a legend

  5. Box-and-Line Diagram Example

  6. Box-and-Line Diagram Heuristics • Make box-and-line diagrams only when no standard notation is adequate. • Keep the boxes and lines simple. • Make symbols for different things look different. • Use symbols consistently in different diagrams. • Use grammatical conventions to name elements. • Don’t mix static and dynamic elements.

  7. UML Notes and Constraints • Note—A dog-eared box connected to model elements by a dashed line • May contain arbitrary text • Used for comments and specifications • Constraint—A statement that must be true of entities designated by model elements • Written inside curly brackets • Beside single model elements • Beside a dashed line connecting several model elements

  8. UML Properties and Stereotypes • Property—Characteristic of an entity designated by a model element • List of tagged values in curly brackets • Tagged value: tag = value • Boolean properties that are true may drop the value and equals sign • Stereotype—A model element given more specific meaning • Shown with icons, colors, graphics • Stereotype keywords between guillemots, for example «interface»

  9. Common Elements Example

  10. UML Dependency Relations • Examples: D uses I, D depends for compilation on I, D imports I • Represented by dependency arrows: stereotyped dashed arrows A dependency relation holds between two entities D and I when a change in I (the independent entity) may affect D (the dependent entity).

  11. Dependency Relation Example

  12. UML Packages • A UML package is a collection of model elements, called package members. • The package symbol is a file folder • Package name in tab if body is occupied, otherwise in the body • Members shown in body or using a containment symbol (circled plus sign) • Often connected by import or export dependency arrows

  13. Package Diagrams • A UML package diagram is one whose primary symbols are package symbols. • Useful for • Static models of modules, their parts, and their relationships • Architectural modeling

  14. Package Diagram Example

  15. Software Components • A software component is a reusable, replaceable piece of software. • Component-based development is an approach in which products are designed and built using commercially available or custom-built software components.

  16. UML Component Diagrams • A UML component is a modular, replaceable unit with well-defined interfaces. • Component symbols are rectangles containing names • Stereotyped «component» or have component symbol in upper right-hand corner • A UML component diagram shows components, their relationships to their environment, and their internal structure.

  17. UML Interfaces • A UML interface is a named collection of public attributes and abstract operations. • Represented by a stereotyped class symbol (later) • Represented by special ball and socket symbols • Note: this use of the term “interface” is different from out previous use as a communications boundary.

  18. Provided and Required Interfaces • A class or component realizes an interface when it includes its attributes and implements its operations. • Providedinterface—Realized by a class or component • Represented by a ball or lollipop symbol • Requiredinterface—Needed by a class or component • Represented by a socket symbol • The assembly connector wires interfaces together.

  19. Interface Symbols Example

  20. Component Internal Structure • Components can contain other components or classes showing how they are built. • A delegation connector ties a component interface to one or more internal classes or components that realize or use the interface. • Solid arrows • Stereotyped with «delegate»

  21. Component Internals Example

  22. Component Diagram Uses • Static models of software components (reusable and replaceable parts) • Model program components • Architectural models • Detailed design models • Relationship to environment • Model internal structure of components

  23. Logical and Physical Architecture • Logicalarchitecture—The configuration of a product’s major parts and their relationships in abstraction from implementation as code on a real machine • Physicalarchitecture—The realization of a product as code and data files residing and executing on computational resources • UML deployment diagrams model physical architecture.

  24. UML Artifacts • A UML artifact is any physical representation of data used or produced during development or operation. • Examples: Files, documents, program code • Artifacts have types and instances • Represented by rectangles containing names • Stereotyped «artifact» or have artifact symbol in upper right-hand corner • Instances have underlined names, types do not • Artifacts realize logical entities (classes, components, etc.)

  25. UML Nodes • A UML node is a computational resource. • Device—A physical processing unit, such as a computer • Executionenvironment—A software system that implements a virtual machine, such as an operating system or language interpreter • Represented in UML by box or slab symbols • Stereotyped with «device» or «execution environment» • Types and instances • Types have names • Instance have underlined labels of the form name : type • Name or type may be suppressed, but not both

  26. Node Symbols Example

  27. Deployment Diagrams • A UML deployment diagram models computational resources, communication paths among them, and artifacts that reside and execute on them. • Used to show • Real and virtual machines used in a system • Communication paths between machines • Program and data files realizing the system • Residence • Execution

  28. Deployment Diagram Rules • Computational resources are nodes • Communication paths are solid lines between nodes • May be labeled • May have multiplicities and role names • Artifact symbols may • Appear within node symbols • Be listed within node symbols • Be connected to node symbols by dependency arrows stereotyped with «deploy»

  29. Deployment Diagram Example

  30. Summary • Box-and-line diagrams are used to make static and dynamic architectural models. • Notes, constraints, properties, and stereotypes can be used in any UML diagram. • Package diagrams are used to model modules and their parts. • Component diagrams are used to model software components. • Deployment diagrams are used to model physical architectures.

More Related