1 / 32

5. Advanced Structural Modeling

5. Advanced Structural Modeling. Interfaces, Types, and Roles. Overview. Interfaces, types, roles, and realization Modeling the seams in a system Making interfaces understandable and approachable. Terms & Concepts.

oprah
Download Presentation

5. Advanced Structural Modeling

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. 5. Advanced Structural Modeling Interfaces, Types, and Roles

  2. Overview • Interfaces, types, roles, and realization • Modeling the seams in a system • Making interfaces understandable and approachable CS6359 Chapter 11

  3. Terms & Concepts • Interface: a collection of operations that are used to specify a service of a class or a component • Type: a stereotype of a class used to specify a domain of objects, together with the operations applicable to the object • Role: the behavior of an entity participating in a particular context. CS6359 Chapter 11

  4. Interfaces ISpell IThesaurus interfaces wordsmith.dll IUnknown component CS6359 Chapter 11

  5. Interfaces • Name: simple names, path names • Operations: unlike classes, interfaces do not specify any structure (no attributes), nor do they specify any implementation (no methods, which provide the implementation of operations). • Relationships: like a class, an interface may participate in generalization, association, and dependency relationships. CS6359 Chapter 11

  6. Interface vs. Abstract Class • An abstract class may have attributes, but an interface may not. • Interfaces span model boundaries. The same interface may be realized by both a class (a logical abstraction) and a component (a physical abstraction that provides a manifestation of the class). CS6359 Chapter 11

  7. Modeling the Seams in a System • Group those that tend to be tightly coupled relative to other sets of classes and components. • Refine your grouping by considering the impact of change • Package logically related sets of cross-boundary operations and signals as interfaces CS6359 Chapter 11

  8. Hints and Tips • A well-structured interface: • Is simple yet complete. Providing all the operations necessary yet sufficient to specify a single service. • Is understandable, providing sufficient information. • Is approachable, providing information to guide the user to its key properties without being overwhelmed by the details of a pile of operations. CS6359 Chapter 11

  9. Summary • Interfaces, types, & roles • Interface vs. Abstract Class • Modeling the Seams of a System • Well-Structured Interface CS6359 Chapter 11

  10. 5. Advanced Structural Modeling Packages

  11. Overview • Packages • Visibility • Importing • Exporting • Standard Elements • Modeling groups of elements CS6359 Chapter 12

  12. Packages • Package—general-purpose mechanism for organizing elements into groups. • Names • Simple name—textual string distinguishing one package from others. • Path name—simple name prefixed by any enclosing package. CS6359 Chapter 12

  13. Packages Depicted simple names Client + OrderForm + TrackingForm Business rules - Order extended packages enclosing package name package name path names Sensors::Vision { version = 2.24 } CS6359 Chapter 12

  14. Client + OrderForm + TrackingForm - Order Owned Elements • Composite relationship • Destroyed if enclosing package is destroyed graphical nesting visibility Client +OrderForm -Order textual nesting +TrackingForm CS6359 Chapter 12

  15. Visibility • You can control the visibility of the elements owned by a package just as you can control the visibility of the attributes and operations owned by a class. • Packages that are friends to another may see all the elements of that package, no matter what their visibility. • If an element is visible within a package, it is visible within all packages nested inside the package. CS6359 Chapter 12

  16. Importing & Exporting • Importing • Grants a one-way permission for elements in one package to access the elements in another package. • Dependency with stereotype <<import>> • Exporting • Public parts of a package. CS6359 Chapter 12

  17. Importing & Exporting Depicted CS6359 Chapter 12

  18. Standard Elements • facade—only a view on some other package. • framework—package consisting mainly of patterns. • stub—a package that serves as a proxy for the public contents of another package. • subsystem—a package representing an independent part of the system being modeled. • system—a package representing the entire system being modeled. CS6359 Chapter 12

  19. Modeling Groups of Elements (steps) • Look for “clumps” of elements that are semantically close to one another. • Surround “clumps” with a package. • Identify public elements of each package. • Identify import dependencies. CS6359 Chapter 12

  20. Summary • Packages • Owned Elements • Visibility • Importing & exporting • Standard package elements • Modeling groups of elements CS6359 Chapter 12

  21. 5. Advanced Structural Modeling Instances, Object Diagrams

  22. Overview • Instances and Objects • Modeling Concrete Instances • Modeling Prototypical Instances • Modeling Object Structures • Forward and Reverse Engineering CS6359 Chapter 12

  23. Instances • The terms “instance” and “object” are largely synonymous; for most part, they may be used interchangeably. • Use instances to model concrete or prototypical things that live in the real world. • Transient: specifies that an instance is created during execution of the enclosing interaction but is destroyed before completion of execution (a standard constraint that applied to objects). CS6359 Chapter 12

  24. Abstractions & Instances • Instances don’t stand alone: they are almost always tied to an abstraction. • Instances of: • Classes (objects) • Components, nodes, use cases, and associations • To indicate an instance, you underline its name. CS6359 Chapter 12

  25. myCustomer id : SSN = “432-89-1738” active = True agent : Other Concepts anonymous instance named instance myCustomer : Multimedia :: AudioStream t : Transaction : keyCode c : Phone [WaitingForAnswer] orphan instance multiobject instance with attribute values r : FrameRenderThread active object instance with explicit state CS6359 Chapter 12

  26. Modeling Concrete Instances (steps) • Identify the instances necessary and sufficient to model the system. • Render these objects in the UML as instances; give meaningful names if possible or render it as an anonymous object. • Expose the stereotypes, tagged values, and attributes. • Show these instances and their relationships in an object diagram. CS6359 Chapter 12

  27. Modeling Prototypical Instances (steps) • Identify those prototypical instances necessary and sufficient to model the system. • Render these objects in the UML as instances; give meaningful names if possible or render it as an anonymous object. • Expose the properties of each instance. • Show these instances and their relationships in an interaction diagram or an activity diagram. CS6359 Chapter 12

  28. Object Diagrams • Object diagrams model the instances of things contained in class diagrams. • Shows a set of objects and their relationships at a point in time. • Used to model the static design view or static process view of a system. • Shows a snapshot of the system at a moment in time and rendering a set of objects, their state, and their relationships. CS6359 Chapter 12

  29. d1 : Department name = “Sales” d2 : Department name = “R&D” d3 : Department name = “US Sales” : ContactInfomation address = “1472 Miller St.” p : Person name = “Erin” employeeID = 4362 title = “VP of Sales” An Object Diagram c : Company link attribute value object anonymous object manager CS6359 Chapter 12

  30. Modeling Object Structures (steps) • Identify the mechanism. • For each mechanism, identify classes, interfaces, and other elements that participate in this collaboration; identify the relationships among these things. • Consider one scenario that walks through this mechanism. Freeze that scenario at a moment in time and render each object that participate in the mechanism. • Expose the state and attribute values of each object. • Expose the links among these objects CS6359 Chapter 12

  31. Forward & Reverse Engineering • Forward engineering an object diagram: possible but limited value. • Reverse engineering an object diagram: very useful in debugging process. • Choose the target and walk through a scenario • Identify the set of objects that collaborate in that context. • Expose these object’s states attribute values and links among these objects. CS6359 Chapter 12

  32. Summary • Instances • Abstractions & Instances • Modeling Concrete Instances • Modeling Prototypical Instances • Object Diagram • Modeling Object Structures • Forward and Reverse Engineering CS6359 Chapter 12

More Related