Components are a slightly fuzzy concept in the UML, because both classes and components can be used to model the same thing. For example, to quote Rum - baugh (one of the UML founders):
The distinction between a structured class and a component is somewhat vague and more a matter of intent than firm semantics. [RJB04]
And to quote the UML specification [OMG03b]:
Acomponent represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and. required interfaces.
Again, this idea can be modeled with a regular UML class and its provided and required interfaces. Recall that a UML class can be used to model any level of software element, from an entire system to subsystem to small utility object.
But when one uses a UML component, the modeling and design intent is to emphasize
UML components are a design - level perspective; they don't exist in the concrete software perspective, but map to concrete artifacts such as a set of files.
A good analogy for software component modeling is a home entertainment system; we expect to be able to easily replace the DVD player or speakers. They are modular, self - contained, replaceable, and work via standard interfaces.
For example, at a large - grained level, a SQL database engine can be modeled as a component; any database that understands the same version of SQL and supports the same transaction semantics can be substituted. At a finer level, any solution that implements the standard Java Message Service API can be used or replaced in a system.
Since the emphasis of component - based modeling is replaceable parts (perhaps to upgrade for better non - functional qualities, such as performance), it's a general guideline to do component modeling for relatively large - scale elements, because it is difficult to think about or design for many small, fine - grained replaceable parts. Figure illustrates the essential notation.
Figure 38.2 UML components
The topic of dedicated component - based modeling and development is a large, specialized subject, outside of the scope of this introduction to OOA/D.
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.