5. Advanced Structural Modeling
32
5. Advanced Structural Modeling Interfaces, Types, and Roles
description
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. - PowerPoint PPT Presentation
Transcript of 5. Advanced Structural Modeling
5. Advanced Structural Modeling
Interfaces, Types, and Roles
Sung KimCS6359
Chapter 11 Slide 2
Overview
• Interfaces, types, roles, and realization• Modeling the seams in a system• Making interfaces understandable and
approachable
Sung KimCS6359
Chapter 11 Slide 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.
Sung KimCS6359
Chapter 11 Slide 4
Interfaces
interfaces
wordsmith.dll
IUnknown
IThesaurusISpell
component
Sung KimCS6359
Chapter 11 Slide 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.
Sung KimCS6359
Chapter 11 Slide 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).
Sung KimCS6359
Chapter 11 Slide 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
Sung KimCS6359
Chapter 11 Slide 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.
Sung KimCS6359
Chapter 11 Slide 9
Summary
• Interfaces, types, & roles• Interface vs. Abstract Class• Modeling the Seams of a System• Well-Structured Interface
5. Advanced Structural Modeling
Packages
Sung KimCS6359
Chapter 12 Slide 11
Overview
• Packages– Visibility– Importing– Exporting– Standard Elements
• Modeling groups of elements
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 13
Packages Depicted
Business rules
+ OrderForm+ TrackingForm- Order
Client
Sensors::Vision { version = 2.24 }
simple names
extended packages
enclosing package name
package name
path names
Sung KimCS6359
Chapter 12 Slide 14
Owned Elements
• Composite relationship• Destroyed if enclosing package is destroyed
+ OrderForm+ TrackingForm- Order
Client Client
+OrderForm
+TrackingForm
-Order
graphical nesting
textual nesting
visibility
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 17
Importing & Exporting Depicted
+Database+LoggingService
Server
+ OrderForm+ TrackingForm- Order
Client
+OrderRules-GUI:Window
Policies <<import>>
+Window+Form#EventHandler
GUI<<import>>
imports
exports
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 20
Summary
• Packages• Owned Elements• Visibility• Importing & exporting• Standard package elements• Modeling groups of elements
5. Advanced Structural Modeling
Instances, Object Diagrams
Sung KimCS6359
Chapter 12 Slide 22
Overview
• Instances and Objects• Modeling Concrete Instances• Modeling Prototypical Instances• Modeling Object Structures• Forward and Reverse Engineering
Sung KimCS6359
Chapter 12 Slide 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).
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 25
Other Concepts
: keyCode
: Multimedia :: AudioStreamt : Transaction
myCustomer
r : FrameRenderThread
c : Phone [WaitingForAnswer]
myCustomer
id : SSN = “432-89-1738”active = True
agent :
named instance
instance with explicit state
instance with attribute values
active object
multiobject orphan instance
anonymous instance
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 29
An Object Diagramc : Company
d1 : Department
name = “Sales”
d3 : Department
name = “US Sales”
p : Person
name = “Erin”employeeID = 4362title = “VP of Sales”
d2 : Department
name = “R&D”
: ContactInfomation
address = “1472 Miller St.”
object
link
attribute value
manageranonymous object
Sung KimCS6359
Chapter 12 Slide 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
Sung KimCS6359
Chapter 12 Slide 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.
Sung KimCS6359
Chapter 12 Slide 32
Summary
• Instances• Abstractions & Instances• Modeling Concrete Instances• Modeling Prototypical Instances• Object Diagram• Modeling Object Structures• Forward and Reverse Engineering
