5 Advanced Structural Modeling Interfaces Types and Roles

  • Slides: 32
Download presentation
5. Advanced Structural Modeling Interfaces, Types, and Roles

5. Advanced Structural Modeling Interfaces, Types, and Roles

Overview • Interfaces, types, roles, and realization • Modeling the seams in a system

Overview • Interfaces, types, roles, and realization • Modeling the seams in a system • Making interfaces understandable and approachable Sung Kim CS 6359 Chapter 11 Slide 2

Terms & Concepts • Interface: a collection of operations that are used to specify

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. Sung Kim CS 6359 Chapter 11 Slide 3

Interfaces ISpell IThesaurus interfaces wordsmith. dll IUnknown component Sung Kim CS 6359 Chapter 11

Interfaces ISpell IThesaurus interfaces wordsmith. dll IUnknown component Sung Kim CS 6359 Chapter 11 Slide 4

Interfaces • Name: simple names, path names • Operations: unlike classes, interfaces do not

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. Sung Kim CS 6359 Chapter 11 Slide 5

Interface vs. Abstract Class • An abstract class may have attributes, but an interface

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). Sung Kim CS 6359 Chapter 11 Slide 6

Modeling the Seams in a System • Group those that tend to be tightly

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 crossboundary operations and signals as interfaces Sung Kim CS 6359 Chapter 11 Slide 7

Hints and Tips • A well-structured interface: – Is simple yet complete. Providing all

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. Sung Kim CS 6359 Chapter 11 Slide 8

Summary • • Sung Kim Interfaces, types, & roles Interface vs. Abstract Class Modeling

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

5. Advanced Structural Modeling Packages

5. Advanced Structural Modeling Packages

Overview • Packages – Visibility – Importing – Exporting – Standard Elements • Modeling

Overview • Packages – Visibility – Importing – Exporting – Standard Elements • Modeling groups of elements Sung Kim CS 6359 Chapter 12 Slide 11

Packages • Package—general-purpose mechanism for organizing elements into groups. • Names – Simple name—textual

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. Sung Kim CS 6359 Chapter 12 Slide 12

Packages Depicted Client simple names + Order. Form + Tracking. Form - Order Business

Packages Depicted Client simple names + Order. Form + Tracking. Form - Order Business rules extended packages enclosing package name Sensors: : Vision { version = 2. 24 } Sung Kim CS 6359 Chapter 12 path names Slide 13

Owned Elements • Composite relationship • Destroyed if enclosing package is destroyed graphical nesting

Owned Elements • Composite relationship • Destroyed if enclosing package is destroyed graphical nesting visibility Client + Order. Form + Tracking. Form - Order Client +Order. Form -Order textual nesting +Tracking. Form Sung Kim CS 6359 Chapter 12 Slide 14

Visibility • You can control the visibility of the elements owned by a package

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. Sung Kim CS 6359 Chapter 12 Slide 15

Importing & Exporting • Importing – Grants a one-way permission for elements in one

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. Sung Kim CS 6359 Chapter 12 Slide 16

Importing & Exporting Depicted Sung Kim CS 6359 Chapter 12 Slide 17

Importing & Exporting Depicted Sung Kim CS 6359 Chapter 12 Slide 17

Standard Elements • facade—only a view on some other package. • framework—package consisting mainly

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. Sung Kim CS 6359 Chapter 12 Slide 18

Modeling Groups of Elements (steps) • Look for “clumps” of elements that are semantically

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. Sung Kim CS 6359 Chapter 12 Slide 19

Summary • • • Packages Owned Elements Visibility Importing & exporting Standard package elements

Summary • • • Packages Owned Elements Visibility Importing & exporting Standard package elements Modeling groups of elements Sung Kim CS 6359 Chapter 12 Slide 20

5. Advanced Structural Modeling Instances, Object Diagrams

5. Advanced Structural Modeling Instances, Object Diagrams

Overview • • • Instances and Objects Modeling Concrete Instances Modeling Prototypical Instances Modeling

Overview • • • Instances and Objects Modeling Concrete Instances Modeling Prototypical Instances Modeling Object Structures Forward and Reverse Engineering Sung Kim CS 6359 Chapter 12 Slide 22

Instances • The terms “instance” and “object” are largely synonymous; for most part, they

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). Sung Kim CS 6359 Chapter 12 Slide 23

Abstractions & Instances • Instances don’t stand alone: they are almost always tied to

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. Sung Kim CS 6359 Chapter 12 Slide 24

Other Concepts anonymous instance named instance my. Customer : Multimedia : : Audio. Stream

Other Concepts anonymous instance named instance my. Customer : Multimedia : : Audio. Stream t : Transaction : key. Code agent : orphan instance multiobject c : Phone [Waiting. For. Answer] instance with attribute values r : Frame. Render. Thread my. Customer active object instance with explicit state Sung Kim CS 6359 Chapter 12 id : SSN = “ 432 -89 -1738” active = True Slide 25

Modeling Concrete Instances (steps) • Identify the instances necessary and sufficient to model the

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. Sung Kim CS 6359 Chapter 12 Slide 26

Modeling Prototypical Instances (steps) • Identify those prototypical instances necessary and sufficient to model

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. Sung Kim CS 6359 Chapter 12 Slide 27

Object Diagrams • Object diagrams model the instances of things contained in class diagrams.

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. Sung Kim CS 6359 Chapter 12 Slide 28

An Object Diagram c : Company d 1 : Department name = “Sales” object

An Object Diagram c : Company d 1 : Department name = “Sales” object d 2 : Department link d 3 : Department name = “R&D” attribute value name = “US Sales” anonymous object manager p : Person Sung Kim name = “Erin” employee. ID = 4362 title = “VP of Sales” : Contact. Infomation address = “ 1472 Miller St. ” CS 6359 Chapter 12 Slide 29

Modeling Object Structures (steps) • Identify the mechanism. • For each mechanism, identify classes,

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 Sung Kim CS 6359 Chapter 12 Slide 30

Forward & Reverse Engineering • Forward engineering an object diagram: possible but limited value.

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. Sung Kim CS 6359 Chapter 12 Slide 31

Summary • • Instances Abstractions & Instances Modeling Concrete Instances Modeling Prototypical Instances Object

Summary • • Instances Abstractions & Instances Modeling Concrete Instances Modeling Prototypical Instances Object Diagram Modeling Object Structures Forward and Reverse Engineering Sung Kim CS 6359 Chapter 12 Slide 32