1. Component Basics CS6961 – Lecture 6 Nathan Dykman

2. University of Utah SoCCS6961 - Lecture 62 What We Covered We have introduced the concepts of class modeling, sequence modeling and use cases –Often, this is the core “triad” of UML models In the next section, we will be introducing component modeling in UML –As well as basic component concepts in software systems.

3. University of Utah SoCCS6961 - Lecture 63 Administration Due date extension: –Project is now due by Friday, 05:14:59PM You can hand it in now, if you just want to get it over with Or you can resubmit if you already handed it in. Any questions? –Okay, moving bravely on.

4. University of Utah SoCCS6961 - Lecture 64 Components Let’s spent a little time and brainstorm about what components are (or could be) –For those of you that haven’t heard the term before, think about it in more general terms.

5. University of Utah SoCCS6961 - Lecture 65 Components –Are a set of consistent software functionality that can be deployed independently Or as an interdependent part of a system –Provide a consistent interface for accessing functionality Allowing the implementation of that functionality to vary independently of that interface.

6. University of Utah SoCCS6961 - Lecture 66 Components and Classes Could classes be considered components? –Independent unit of deployment? Sort of. (.class files,.netmodule,.lib) –Consistent Interface Sure. We have public methods, etc. –Implementation/Interface independence? Depends on how the class coded, it seems.

7. University of Utah SoCCS6961 - Lecture 67 Components and Classes Okay, what if we add in interfaces –Java, C# interfaces (C++: Pure Virtual Classes) –Helps with implementation/interface independence. So, what makes components different from classes?

8. University of Utah SoCCS6961 - Lecture 68 Component Key Ideas Key idea: Components can be (ideally) deployed independently in a system –So, you should be able to add a new version of a component to a system without having to rebuild (or link) the whole system Why is this important? –What do you need to have to make this work? Hint, think runtime and design time.

9. University of Utah SoCCS6961 - Lecture 69 Components Key Idea: Components are a reification of the concept of a class applied to a set of classes. –In lay terms, classes map to components like so Public Methods  Public Interfaces Private Methods  Private Classes –In a sense, we can treat a whole set of classes in a “class-like manner”

10. University of Utah SoCCS6961 - Lecture 610 APIs to Frameworks For a long time, we had libraries that provide a set of calls to other programs –Standard C library, Base Win32 Library, POSIX/Unix libs, etc. Still a very useful programming model In modern programming languages, we want OO-based APIs –We call these frameworks

11. University of Utah SoCCS6961 - Lecture 611 Frameworks in C++ C++ provides a set of OO libraries, of course –IOStreams, STL, Boost. However, reuse at the binary level is very tricky. –In fact, in the worse case, you have to recompile a program to a new version of a library In the best case, you can relink, but…

12. University of Utah SoCCS6961 - Lecture 612 C++ and Headers Just like C, you need header files to be able to use a library. –All those #include statements are important. Also, there is no standard binary linkage for C++ classes –Since C++ was first built on top of the C linker, OO information was stripped out of the binaries Templates make this even more complicated.

13. University of Utah SoCCS6961 - Lecture 613 COM and CORBA While we don’t cover either of these in much detail, both of these technologies try to address this problem of reusing objects in C++ –COM is a MS technology, still widely used –CORBA is used more often in distributed object worlds, being replaced by Java,.Net and Web Service technologies.

14. University of Utah SoCCS6961 - Lecture 614 Components in Modern Languages Newer languages solve the header problem by compiling the OO information alongside the bytecode for the class –This means that in the best case, we don’t need to even relink a program to use a newer library of classes The class loader takes care of all the binding we need at runtime.

15. University of Utah SoCCS6961 - Lecture 615 Components in Modern Languages This information allows us advanced capabilities like reflection –Without having this information, reflection at runtime can’t work. In some cases, reflection can be very powerful –JUnit requires it, as do many other frameworks in Java,.Net, etc.

16. University of Utah SoCCS6961 - Lecture 616 Components in UML Components in UML provide an design abstraction that matches the basic ideas of components. –A component in UML can provide a set of classes, interfaces to other components, etc. This set of element is called the component interface. –A component in UML can realize a set of classes, etc. that implements the component interface

17. University of Utah SoCCS6961 - Lecture 617 Components in UML Additionally, UML supported the concept of a required interface –This shows that a component requires another component to provide an compatible interface to use its functionality –This is not directly supported in any standard programming framework yet –But it is a useful and common concept Work in contract languages reflects this.

18. University of Utah SoCCS6961 - Lecture 618 Components In UML There are a number of notational variations in UML to show component models –Each shows a level of detail. –There are also some tool variations in the notational variations supported This is annoying at best For example, the compartment view isn’t very commonly supported

19. University of Utah SoCCS6961 - Lecture 619 Component Model: Lollipop View

20. University of Utah SoCCS6961 - Lecture 620 Lollipop View In this case, the provided interfaces are shown as circles, and there is an association between component to interface (this is the lollipop) –These are classes/interfaces, but with no details shown (only name) The solid line from a component to a class shows that the component provides the interface A dashed arrow line from component to interface shows that the component requires the interface.

21. University of Utah SoCCS6961 - Lecture 621 Component Model: Expanded View

22. University of Utah SoCCS6961 - Lecture 622 Expanded View This is the same as the previous example, but the interfaces are now expanded to show detail –I don’t prefer this view, as it is often more cluttered that is required. Also, some tools show provided interfaces with an implements relationship –Shown as a dashed line with a open triangle from component to interface

23. University of Utah SoCCS6961 - Lecture 623 Compartment View (RSA)

24. University of Utah SoCCS6961 - Lecture 624 Compartment View Rational Software Architect supports a compartment view of components –The second compartment is the required interfaces –The third compartment is the provided interfaces –Components are then associated with each other. (plain line, no arrows).

25. University of Utah SoCCS6961 - Lecture 625 Warning: UML Distilled In chapter 5, there is talk about “Ball and Socket Notation” –This allows a component to show a required interface as a socket. This is still allowed. –But the notation showing an assembly as a connected ball and socket is no longer supported. However, some tools still use it. This is bad.

26. University of Utah SoCCS6961 - Lecture 626 Bad Example

27. University of Utah SoCCS6961 - Lecture 627 Advanced Concepts UML also supports the concept of a port for components –A port is a specific connection point for interfaces (both provided and required). It can serve as a “gate for messages” as well. –Useful in modeling SOA-based or event- based software systems. –We will discuss this more later when we cover structured classes and composite structures.

28. University of Utah SoCCS6961 - Lecture 628 Component Structure Components can have artifacts –These represent the physical files, resources, etc. of a component Components can nest –Components can contain other components There is a practical limit to how this nesting works.

29. University of Utah SoCCS6961 - Lecture 629 Components and Subsystems For large scale projects, it makes sense to split the system into subsystems –Subsystems provide a set of components to other subsystems and systems –Subsystems have a set of components that implement/support those provided components.

30. University of Utah SoCCS6961 - Lecture 630 Subsystem Examples

31. University of Utah SoCCS6961 - Lecture 631 Model Management If you remember, UML has packages –Packages can contain any elements –This allows us to organize UML models into a hierarchy (much like a file system) Subsystems are modeled in UML as a special kind of package –Technically, a stereotype of package.

32. University of Utah SoCCS6961 - Lecture 632 Next Time: We discuss the reason behind the use of components, and the relationship of components to architecture –Later on, we will discuss more concepts in software architecture Reading: I recommend you check out Chap. 4,5 and 14 in UML Distilled –I may have a paper for reading as well.