You can also see that both diagrams use the lollipop symbol to indicate an implemented interface although the UML 2 version introduces the socket symbol to indicate a required interface. Both diagrams model dependencies, either between components or between components and interfaces. As you can see UML 2 uses this symbol as a visual stereotype within the rectangle to indicate that the rectangle represents a component although the textual stereotype of component is also acceptable (as you see with the Schedule component). UML 2 components are modeled as simple rectangles, whereas in UML 1.x there were depicted as rectangles with two smaller rectangles jutting out from the left-hand side. As you can see, there are several notational differences. Figure 2 depicts the same diagram using UML 1.x notation. Figure 1 presents an example component model, using the UML 2 notation, for the university system. You will discover the need to evolve the interfaces to reflect new requirements or changes to your design as your initiative progresses, changes that need to be negotiated between the subteams and then implemented appropriately. Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between subteams. UML component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components. Your initial architectural modeling efforts during cycle 0 should focus on identifying the initial architectural landscape for your system. In fact I’ll often iterate back and forth between these diagrams.Component diagrams are particularly useful with larger teams. Physical architecture issues, in particular hardware issues, are better addressed via UML deployment diagrams or network diagrams. I typically use UML 2 component diagrams as an architecture-level artifact, either to model the business software architecture, the technical software architecture, or more often than not both of these architectural aspects. Component-based development (CBD) and object-oriented development go hand-in-hand, and it is generally recognized that object technology is the preferred foundation from which to build components.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |