Overview

Document Sample
Overview Powered By Docstoc
					Chapter 3: UML The Unified Modeling Language

1

Exercises
1. What were the goals of the creators of the UML? Which methodologies had a prominent impact on the UML? 2. What are the essential differences between building a dog’s house and building a high-rise building? How do these differences affect the degree to which a model is valuable? 3. What are the four reasons that make us model? 4. What effect does the choice of models have in how we approach a problem and develop a solution? 5. Why do we need to be able to view a model from different levels of detail? 6. What are the structural things in the UML? 7. What are the behavioral things in the UML? 8. Complex systems, the natural habitat for the UML, are by definition too big or too complex or both. We need a grouping mechanism to help us organize elements into groups. What do we call that in the UML? 9. Describe the four basic relationships in the UML in the context of their coupling strength and list other relationships which are important but are special cases of these basic four 10. What is an UML diagram and why do we use a limited number of them? 11. What are two dimensions along which are divided object-oriented systems in the UML? 12. What are the extensibility mechanisms in the UML and why do they exist? 13. Enumerate and describe the views which make up a system’s architecture as proposed and supported by the UML. 14. Explain what class diagrams are and what kind of information they convey. 15. Explain what object diagrams are and what kind of information they convey. 16. Explain what use case diagrams are and what kind of information they convey. 17. Which are the two kinds of interaction diagrams and how do they differ? 18. Explain what activity diagrams are and what kind of information they convey. 19. What are the principal applications of the activity diagram? 20. Explain what statechart diagrams are and what kind of information they convey. 21. Define the central terms used in a statechart diagram. 22. Explain what component diagrams are and what kind of information they convey. 23. Which criteria may we use for choosing a set of components for a component diagram? 24. Explain what deployment diagrams are and what kind of information they convey.

• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

2

Answers
1. The methodologies of the three foremost authorities and pioneers of the object-oriented paradigm had a prominent impact in the creation and architecture of the UML. Their methodologies were known as the Booch method, the OOSE method and the OMT method. The UML was created within the context of the following goals: a. To model systems, from concept to executable artifact, using object-oriented techniques b. To address the issues of scale inherent in complex, mission-critical systems c. To create a modeling language usable by both humans and machines 2. The basic difference between building a dog’s house and building a high-rise building is one of complexity. For the dog’s house, requirements are simple and fit in your mind all at once; the architectural alternatives are limited and have no far-reaching consequences; the client is not demanding and will be easily pleased as long as the roof has no leaks. Instead, the clients of the high-rise building are likely to ask for a myriad of details, and the mere dimensions of the project exact a correspondingly large effort in order to evaluate all the alternatives and come up with reasonable solutions. There will be multiple aspects of the building that will demand our attention, from its general architecture, to issues regarding its appearance, to physical-structural aspects whose careful consideration will determine whether the building stands or falls, to its interior design, to its security precautions, etc., becoming clearly impossible to mentally hold the complete project in our minds all at one time. It is in projects of such magnitude that the need for models becomes evident. We are in desperate need to simplify, but we mustn’t omit a single relevant detail. All aspects must be accounted for, and yet not require to be present at the same time for them to make sense. It is as if we were looking for a loosely coupled collection of models, each one highly cohesive and easy to understand. Funny how we are back to Chapter 2. We are in fact, asking for an object-oriented set of models to help us illustrate object-oriented systems! This resurfacing of the principles that constitute the object-oriented paradigm is only one more confirmation of their strength and how their roots lie so closely to our cognition. 3. We model for different reasons at different moments in time. At some point our focus may be the need to visualize a system, either as it stands right now or as we want it to be; because of the high degree of complexity that typically characterizes interesting systems, being able to see in a clear and organized fashion becomes an inescapable necessity. At other times we may need to specify in precise, unambiguous and complete manner the structural and behavioral aspects of a system. Of course, the ultimate goal of development is the construction of working code that complies with the specifications; in fact many of the constructs used by the UML have a direct or indirect correspondence with constructs available in most object-oriented languages, while others are useful in database modeling or network layout. The ideal role of the UML in the construction of software systems is only realized if we have tools that support both forward as well as reverse engineering – sometimes these two capabilities are referred to as one single feature: round-trip engineering1. Last but not least, we model in order that we may document our decisions and because we believe a software system is incomplete if its only component is code. 4. The choice of models at every crossroad can either shine and simplify the most intricate problems or confuse us, by focusing on a set of irrelevant ideas. The reason for this is that models, as a kind of language, have important influence on the way we think and what we can
1

This term has been around in the object-oriented literature at least since [BOOCH1991].
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

3

think about. This is similar to mind-sets: how often does a problem seem unsolvable because we are looking at it from an incorrect mind-set, one that doesn’t focus on the relevant ideas? Isn’t the solution often impressively simple to achieve once we realize that we need a change in perspective, a change in mindset? And, isn’t a model very similar indeed to holding a particular mindset? Therefore, the multi-faceted nature of a modeling language as rich as UML must be accompanied by adequate guidance to help us choose the most productive and relevant models at each step of the way in the creation of a software system. This guidance may be a full development process such as the Rational Unified Process (RUP) or at the very least a collection of heuristics for choosing the most relevant and appropriate models. 5. In order to address issues of scale, that are inherent in the large and complex systems we face today, we need models that can be expanded into rich detail and collapsed into high level overviews. Software development is an activity that by its very nature demands that the developer work simultaneously at different levels of abstraction. We need this in object orientation even more so because its rules and principles, as seen in Chapter 2, support and demand the continuity of the object model, from business modeling, through analysis, design and implementation and finally into evolution. We have one single paradigm connecting layers at very distinct levels of abstraction. As we make design choices, they will affect these different layers and different aspects of the whole system and the only way to verify the adequacy of such choices is to be able to move up and down the abstraction dimension of the different models offered by the UML language which as a whole should provide an accurate representation of the software system. 6. The structural things in the UML are the nouns of the UML models representing elements that are either conceptual or physical. These are: a. Classes and interfaces, and variations of classes as in actors, signals and utilities b. Collaborations defining an interaction between a society of roles2 and other elements that work together to provide some cooperative behavior that is bigger than the sum of all the elements. They have, therefore, structural and behavioral dimensions which can be represented in class and interaction diagrams respectively. c. Use cases, which describe a set of sequences of actions that a system performs within an interaction with one or more actors, yielding an observable result of value to one or more of these actors. A use case is realized by a collaboration. This step must be done with utmost care since the developer with a prejudice to seeing things through the algorithmic model can perhaps more easily decompose the various use cases into procedures than step into the new perspective and search for a minimal set of objects, each with well defined capabilities, whose collaboration is able to yield the required functionality. d. Active classes are classes whose instances contain one or more processes or threads and therefore have an initiating or controlling role. Its instances imply concurrent execution with other instances. Active classes are usually either a process or a thread e. A component is different from the previous things in that it represents something physical and replaceable in the system – rather than something conceptual. It provides the implementation of a set of interfaces (usually at least one interface) and may depend on interfaces supplied by other components. There is a wide variety of component types from source files, executables, library (could be a .NET or Java Beans component), database table, ordinary file, ordinary document. A component typically represents the
2

The instances of a class may play different roles at different times. When we focus in a particular interaction then we are mostly interested in the particular role being played by an instance of a class and only in second place is the class relevant.
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

4

physical packaging of several conceptual things like classes, interfaces and collaborations. f. A node is another physical element and it represents a computational resource, usually a computer or device. It may have memory and a processor. It may host a set of components that may be moved from one node to another. 7. The behavioral things in the UML are the verbs of the models, representing behavior over time and space, such as: a. Interaction is a behavior that includes the exchange of a set of messages among a set of objects within a particular context to accomplish a specific purpose. Interactions may specify the behavior of a society of objects or of an individual operation. b. A state machine is a behavior that specifies sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. The behavior of an individual class or a collaboration of classes may be specified with a state machine. 8. Packages are the general purpose mechanism for organizing elements into groups in the UML. The grouped elements may be structural, behavioral or even other packages such that recursion is frequently necessary and convenient. 9. The four basic relationships in the UML, in order of decreasing coupling are generalization, realization, association and dependency. Generalization implies a white box reuse of both specification and implementation therefore representing the highest possible coupling amongst classifiers. Realization comes in second place because it only inherits a specification and not an implementation. The third place is given to association because it tends to be implemented by the embedded instance of one class in another and is therefore a class-wide dependency. At the last position we have dependency, which is the resulting basic relationship whenever it is not possible to verify a stronger coupling. It is created, for example, when one or more methods of one class use instances of another class to accomplish their objectives but these other instances are either created within the method or received as parameters. From these basic relationships, we derive others such as: refinement, trace, include, extend, usage and instantiate. 10. Diagrams in UML are graphical representations of a subset of the elements in a system, often rendered as a connected graph of vertices – which represent things – and arcs – which represent relationships. In the interest of clarity and to emphasize a particular perspective, we often omit certain elements or attributes of some elements from a diagram. Likewise, we may include the same element in different types of diagrams to illustrate different aspects of it. Instead of promoting the undisciplined mixture of things and relationships in as many combinations as are mathematically possible, UML defines a set of nine diagrams which are supportive of the five most useful views3 that as a whole describe the architecture of a software system. 11. In object-oriented systems, there are two especially important dimensions in which the world gets divided. a. The first is the division between a classifier and an instance, easily demonstrated by the relation between a class and its objects. A class represents an abstraction; an object represents a concrete manifestation of that abstraction. This particular dimension carries over into other types of classifiers, such as use cases and use case instances, components and component instances, nodes and node instances. The UML notation for both classifiers and instances is the same except that instances have their names underlined.
3

A view is a projection of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective. Views are an essential part of the architectural description of a system.
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

5

b. The second common division is the separation between interface and implementation, a central theme in object orientation. An interface declares a set of operations that make cohesive sense. An implementation of an interface represents one concrete realization of that interface, responsible for faithfully carrying out the interface’s complete semantics. In the UML we can model both interfaces and their implementations very clearly. The constructs that represent implementations of interfaces are: classes, subsystems and components. However this dichotomy is also applicable to use cases and the collaborations that realize them, as well as operations and the methods that implement them. 12. The creators of the UML were sensible enough to recognize the fact that it is not possible to create a complete modeling language capable of capturing all nuances of meaning we might find desirable to express. Therefore they provided three principal mechanisms through which the semantics of the UML could be expanded as needed. These are: a. Stereotypes are a sub-classing mechanism, enabling the creation of new types of building block that inherit the semantics and behavior of the original building block while adding some of their own. A good example occurs in the Rational Unified Process (RUP) for object-oriented development where it is very useful to classify analysis classes into boundary, control and entity subtypes. With stereotypes, the modeler can make these subtypes first class citizens, just as if they had been defined directly in the UML. Stereotypes are represented in two ways: by placing the stereotype name inside <<>> symbols (e.g. <<boundary>>), or by using a specially selected icon for it b. Tagged values are another extension mechanism, allowing us to create new information in an element’s specification. As the name suggests, it is based on specifying a name/value pair such as those used in dictionaries. A simple but frequently useful example is the desire to keep the version number associated with a particular system element. This can be easily accomplished by placing a label such as {version=2.1} inside the UML element. c. A constraint is the means to provide additional rules or modify existing ones. For example, we might desire to constrain a relationship so that its elements are kept in a certain order. This can be done with an {ordered} annotation. 13. There are five interrelated views that describe the architecture of a system, where each view is a projection into the organization and structure of the system focusing on a particular aspect of that system. These views receive full support from the UML in the form of static and dynamic diagrams. The static aspects of these views are specific for each view but the dynamic aspects are described by using any suitable combination of one or more interaction diagrams, statechart diagrams, activity diagrams and use-case diagrams. The views have a very tight integration among them: nodes in the deployment view hold components from the implementation view that, in turn, represent the physical realization of the classes, interfaces, collaborations and active classes from the design and process views. These views are: a. The use case view of a system includes the use cases that describe the behavior of the system as seen by its end users, analysts and testers. This view doesn’t really specify the organization of a software system4. Rather, it exists to specify the forces that shape the system’s architecture. The static aspects of this view are captured in use case diagrams.

4

Actually, its functional characteristics have to be appropriately dealt with so as to prevent novices from starting a functional decomposition from the use cases.
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

6

b. The design view of a system includes the classes, interfaces and collaborations that constitute the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system, i.e. the services it should provide to its end users. The static aspects of this view are captured in class diagrams and object diagrams. c. The process view of a system is concerned with the processes and threads that form the system’s concurrency and synchronization mechanisms This view primarily addresses the performance, scalability, and throughput of the system. Using UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as the design view, but focusing on the active classes that represent its threads and processes. d. The implementation view of a system deals with the components and files that are used to assemble and release the physical system. This view is primarily concerned with the configuration management of the system’s releases, which is composed of somewhat independent components and files that can be assembled in various ways to produce an executable system. The static aspects are represented in component diagrams. e. Finally, the deployment view of a system includes the nodes that form the hardware topology on which the system will execute. This is the place where hardware meets software. The view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system. This view is very relevant in today’s increasingly distributed systems. The static aspects of this view are captured in deployment diagrams. 14. Class diagrams are the most widely used type of diagram in all the UML. They are used early in development as a means to capture and document the key abstractions in the problem domain. In these cases, it is customary to stay at a very abstract level, and each class should actually be seen as representing a concept – perhaps leading to a software class but not necessarily. It is also possible to represent associations, compositions, aggregations, dependencies and generalization/specialization hierarchies, as needed to cover what we learn about the problem domain or business context. Later in the development process, the classes do have a software representation and they become an abstracted view of the class structure of our software solution. Interfaces supplied by classes and classes’ dependencies on interfaces are also a very important part of a class diagram in that they visually express one of the two dimensions upon which we divide our systems. Class diagrams abstract the structure of the classes whose instances collaborate in order to provide the different functionalities present in a software system. 15. Object diagrams show a set of objects and their relationships at some point in time. The relationships between objects are called links. These diagrams allow us to model static data structures. When we model the static design view or static process view of a system, we usually use object diagrams to model object structures. Object diagrams are snapshots of executing interactions, a freezing in time of the objects and their links as they participate in an interaction. We use these diagrams to visualize, specify, construct and document the existence of important instances in our systems, together with how they are linked and how they see each other. 16. Use case diagrams are one of the five diagrams in the UML used for modeling the dynamic aspects of systems. With them we can model the behavior of a system, a subsystem, a class or an interface. Each diagram shows a set of use cases, the actors and their relationships. Actors are external agents that interact with the element being modeled (usually the system). We use the use case diagrams to model the use case view of a system. Essentially, this involves modeling the context of a system, subsystem, class or interface, or modeling the required behavior of these elements. Use case diagrams make systems, subsystems, classes and interfaces approachable and understandable by presenting an outside perspective of how these elements may be used in
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

7

context. Never does a use case diagram illustrate how the behavior expected from its elements will be accomplished. When modeling a class, for instance, the actors of the diagram will be the classes with which the main class interacts. Subsystems and interfaces modeled by use case diagrams experience a similar situation. 17. Interaction diagrams show an interaction, i.e. a behavior characterized by a set of messages exchanged between a set of objects within a particular context in order to fulfill some functionality. These diagrams model the dynamic aspects of a system. There are two types of interaction diagrams: the sequence diagram and the collaboration diagram. Semantically they are equivalent. This means that conversion between them is possible without loss of information. This is so because they share the same underlying model. Nevertheless, they do not explicitly visualize the same information. The collaboration diagram for instance, emphasizes the object structure and often uses path stereotypes to indicate what kind of link exists between two objects in the diagram. The sequence diagrams on the other hand, visualize message return values which have no place in collaboration diagrams. As to the ordering of messages, collaboration diagrams sequences the messages by associating a number to each message, while sequence diagrams take a bi-dimensional form with the participating objects placed along the horizontal axis and an inverted vertical axis representing time. Thus, compared to collaboration diagrams, sequence diagrams are a bit more graphical in regards to the order in which messages are exchanged. Interactions not only occur among instances of one or more classes; in a more extended sense, interaction diagrams may very well represent the interaction of instances of interfaces, components, nodes and use cases. Furthermore, although their main purpose and application is to describe the flow of control associated with some particular execution (instance) of a use case, these diagrams are able to model the collaboration of any group of instances as long as they share a common purpose or functionality. 18. Activity diagrams are one of the five diagrams in the UML used for modeling the dynamic aspects of systems. It has its roots in the humble flowchart of the prehistoric software engineering age. It differs from other dynamic diagrams, in particular from interaction diagrams, in that it emphasizes the flow of control from activity to activity instead of emphasizing the flow of control from object to object. An activity is a continuing non-atomic execution within a state machine. The non-atomicity means that the activity can be interrupted. Activities ultimately result in some action, which results in a change in state of the system or the return of a value. Actions include calling another operation, sending a signal (similar to an asynchronous call), creating or destroying an object, or performing a pure computation, such as evaluating an expression. In this kind of diagram, we have essentially two kinds of states: activity state and action state. Action states are atomic and thus uninterruptible by events. The associated work is usually considered to take insignificant execution time although in reality it really does not matter if it actually takes considerable time. In contrast, an activity state is composite and implies an internal activity diagram. We only model an activity as an activity state when we care to detail the underlying complexity of the implied activity diagram. Otherwise we stick with action states. After a state (activity or action) is finished executing, transitioning into another state becomes possible as long as any guard expressions are satisfied. These conditional expressions also help in picking a transition amongst several that move out from the current state. The transition whose guard expression evaluates to true will fire and the target state will begin executing. On the contrary, if there is only one possible transition and it has no guard expression, an implicit transition will occur as soon as the source state is finished executing. Although activity diagrams do not emphasize flow of control from object to object, they do allow the modeling of objects
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

8

whose state is changed by the execution of some activity or action. Also, it is possible to model concurrency by using the fork and join constructs, and the diagram can be partitioned into semantically cohesive areas by a mechanism called swimlane. And of course, as a proud descendent of the flowchart, it supports notation for branching. 19. The activity diagram is mostly used to model complex workflows such as business processes that must be understood and verified with domain experts. This could partially or completely become a use case or a group of related use cases. The other important use is in modeling a complex operation usually with the goal of better understanding it before we attempt to distribute responsibilities among a collection of interacting objects. 20. Statechart diagrams are one of the five diagrams in the UML used for modeling the dynamic aspects of systems. It is a view into a state machine. An activity diagram is a special case of a statechart diagram the conditions being that most of the states are activity states and most, if not all, of the transitions are triggered by completion of activities in the source state (in other words, not as a response to the reception of an external event). These diagrams are principally used to model the behavior of reactive objects, i.e. objects whose behavior is best described by their responses to external events. The typical contexts in which statechart diagrams are drawn are: the system as a whole, a subsystem or a class. It is also often useful to attach a statechart diagram to use cases, to model a scenario. 21. In order to understand a statechart diagram and make correct use of it, it is necessary that we understand the meaning of the central terms upon which such a diagram is built. A state is a condition or situation in the life of an object5 during which it satisfies some condition, performs some activity, or waits for some event. An event is an occurrence of a stimulus that can trigger a state transition. A transition is a relationship between two states indicating that an object in the first state will perform certain specified actions and enter the second state when a specified event occurs and specified conditions [if any] are satisfied. There are two basic types of states: simple or composite. A composite state is a state that consists of either concurrent sub-states or disjoint sub-states. Transitions may be labeled with a phrase whose syntax is “event [condition] / action”, where all three tokens are optional. The transition will fire if the event occurs and the condition is satisfied, and will execute the atomic action. If no event is specified then the transition is ready to fire as soon as any activities in the first state are done, and when the condition is either satisfied or missing. If no action is specified then the transition just makes the object change from the first to the second state. 22. Component diagrams are for modeling the physical aspects of object-oriented systems; they show the organization and dependencies among components, such as executables, libraries, tables, files and documents. The perspective from which these diagrams are drawn is the static implementation view of a system. These diagrams help us model the composition of an executable release into its constituent parts (components) and should also distinguish each component with an appropriate stereotype because of the inescapable diversity in the types of the components that can make up a system. Another critical benefit these diagrams bring is the graphical depiction of component dependencies, some of which will be detailed at the interface level. 23. An important thing to keep in mind is that it is usually not very useful to create a component diagram that includes all participating components in a system. Rather, we want to be able to

5

Be careful not to apply a very narrow connotation to the use of the word object in this context. It does not always represent an instance of a class; sometimes it may refer to an instance of a system, subsystem, or even to a given scenario of a use case.
• MSc. Juan Dent H. •

Chapter 3: UML The Unified Modeling Language

9

partition subsets of components and present them in separate diagrams. How do we choose which components to show in a same diagram? a. Those that will or already reside on the same node b. Those that will be installed in every node in the system. c. Those that directly contribute to a particular functional aspect of the system. d. Those representing tables in a database and their relationship to the logical database schema expressed as classes. 24. Deployment diagrams are the complement to component diagrams as to modeling the physical aspects of systems. They show the run time configuration of processing nodes and the components that live on them and may also contain packages or subsystems to deal with scale. Systems that live entirely within one computer and interact with all its hardware devices via the operating system probably do not benefit from deployment diagrams – aside explicitly stating such architecture. They become very useful as soon as the devices the system interacts with are not under operating system control and/or when the system is physically distributed across multiple processors and/or sites. Systems that have the previous characteristics include: embedded systems, because there is a need to model the devices and processors that constitute the system, and any non-monolithic system such as those built with the client/server or the increasingly popular distributed architectures (3-tier or N-tier).

• MSc. Juan Dent H. •


				
DOCUMENT INFO