Essentials of Visual Modeling w/ UML Instructor Notes

Essentials of Visual Modeling w/ UML 2.0 - Instructor Notes
IBM Software Group Essentials of Visual Modeling with UML 2.0 Principles of Visual Modeling

Objectives Describe the importance of visual modeling. Define the four principles of visual modeling. Explain what the Unified Modeling Language (UML) represents. Introduce the objectives for this module.

Where Are We? What is modeling? Four principles of visual modeling The UML Explore the student’s knowledge of modeling.

What Is a Model? A model is a simplification of reality. Define what is meant by the term “model.” According to Grady Booch, IBM Fellow, a model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000-foot view of the system under construction. A good model includes those elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.

Why Model? Modeling achieves four aims: Helps you to visualize a system as you want it to be. Permits you to specify the structure or behavior of a system. Gives you a template that guides you in constructing a system. Documents the decisions you have made. You build models of complex systems because you cannot comprehend such a system in its entirety. You build models to better understand the system you are developing. Sell the students on the value of visual modeling. Clarify that you are discussing formal modeling, not modeling written on a white board or on the back of a napkin at lunch. According to Booch in The Unified Modeling Language User Guide, modeling achieves four aims: 1. Models help you to visualize a system, as you want it to be. A model helps the software team communicate the vision for the system being developed. It is difficult for a software team to have a unified vision of a system that is described only in specification and requirement documents. Models bring about understanding of the system. 2. Models permit you to specify the structure of behavior of a system. A model allows how to document system behavior and structure before coding the system. 3. Models give a template that guide you in constructing a system. A model is an invaluable tool during construction. It serves as a road map for a developer. Have you experienced a situation where a developer coded incorrect behavior because he or she was confused over the wording in a requirements document? Modeling helps alleviate that situation. 4. Models document the decisions you’ve made. Models are valuable tools in the long term because they give “hard” information on design decisions. You don’t need to rely on someone’s memory.

Where Are We? What is modeling? Four principles of visual modeling The UML Transition to the next subject.

Four Principles of Modeling
Essentials of Visual Modeling w/ UML Instructor Notes Four Principles of Modeling The model you create influences how the problem is attacked. Every model may be expressed at different levels of precision. The best models are connected to reality. No single model is sufficient. Demonstrate that there are guiding principles for visual modeling. It is not chaotic activity. The four modeling principles are described in detail on the next four slides. See the “UML User Guide” for a more detailed discussion on these four principles. Modeling has a rich history in all the engineering disciplines. The four basic principles of modeling are derived from this history. The models you create profoundly influence how a problem is attacked and how a solution is shaped. Every model may be expressed at different levels of precision. The best models are connected to reality. No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.

Principle 1: The Choice of Model is Important
Essentials of Visual Modeling w/ UML Instructor Notes Principle 1: The Choice of Model is Important The models you create profoundly influence how a problem is attacked and how a solution is shaped. In software, the models you choose greatly affect your world view. Each world view leads to a different kind of system. Remind students that each model should reflect the problem that they are trying to solve. The model of a system comprises many different views of that system. Refer students to the “Architectural Blueprints -The 4+1 View of Software Architecture” by Phillipe Kruchten. You can find the white paper at Discuss the views later in this module. Supplement this slide with the following example. To build a home, you would use different models to resolve structural and electrical problems. The right models illuminate the most difficult development problems, offering insight that you could not gain otherwise. The wrong models mislead you, causing you to focus on irrelevant issues. In software, the models you choose can greatly affect your world view. If you build a system through the eyes of a database developer, you’ll likely end up with entity-relationship models that push behavior into stored procedures and triggers. If you build a system through the eyes of an object-oriented developer, you’ll end up with a system that has its architecture centered around many classes and patterns of interaction that direct how those classes work together. Each world view leads to a different kind of system with different costs and benefits. (The Unified Modeling Language User Guide, Booch, 1999.) Deployment Model Process Model Design Model

Principle 2: Levels of Precision May Differ
Essentials of Visual Modeling w/ UML Instructor Notes Principle 2: Levels of Precision May Differ Every model may be expressed at different levels of precision. The best kinds of models let you choose your degree of detail, depending on: Who is viewing the model. Why they need to view it. Remember, there are many different ways to view a model of a solution. Again, point out that there is no one mega-model that displays everything about a system. Additional examples from building a home may include examples that the homebuyer may be interested only in the elevation and the floor plan. Obviously, the construction foreman is going to need a more detailed view of the home. If you are building computer chips, sometimes you need a 30,000-foot view. For example, you need your investors to visualize the end product. Other times, you need to get down to the level of the circuits. When developing a GUI system, a quick and dirty executable model of the user interface may be all you need to communicate your intentions. Other times, when you are dealing with cross-system interfaces of network bottlenecks, you need to model down to the bit level. In either case, the best models are those that let you choose your degree of detail, depending on who is doing the viewing and why they need to view it. (The Unified Modeling Language User Guide, Booch, 1999.) View for Customers View for Designers

Principle 3: The Best Models Are Connected to Reality
Essentials of Visual Modeling w/ UML Instructor Notes Principle 3: The Best Models Are Connected to Reality All models simplify reality. A good model reflects potentially fatal characteristics. A model should accurately reflect the real world. A physical model of a building that doesn’t respond the same way as the real materials has limited value. It’s best to have models that have a clear connection to reality. Where that connection is weak, you need to know exactly how those models are divorced from the real world. All models simplify reality. The trick is to be sure that your simplifications don’t mask any important details. A good model reveals any potentially fatal flaws in design. (The Unified Modeling Language User Guide, Booch, 1999.)

Principle 4: No Single Model Is Sufficient
Essentials of Visual Modeling w/ UML Instructor Notes Principle 4: No Single Model Is Sufficient No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models. Create models that can be built and studied separately, but are still interrelated. Many interrelated models are needed to accurately describe a system. Introduce the 4+1 views of architecture first. It’s important that they understand from the beginning that the models created/read represent a specific view of the system. Logical View Implementation View The key phrase is “nearly independent,” meaning that models can be built and studied separately, but are still interrelated. To understand the architecture of object-oriented systems, you need several complementary and interlocking views. An architectural view can be defined as a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. Views are “slices” of models. Each of the views below may have structural and behavioral aspects. Together, they represent the blueprints of a software system. Use-case view exposing the requirements of the system Logical view capturing the vocabulary of the problem space and the solution space Process view modeling the distribution of the system’s processes and threads Implementation view addressing the physical realization of the system Deployment view focusing on system engineering issues To address these different needs, Rational has defined the “4+1 view” architecture model. Remember that not all systems require all views. The number of views is dependent on the system you’re building. For example, a single processor does not require a deployment view or a small program does not require an implementation view and so on. Analysts/Designers Programmers Structure Software management Use-Case View End-user Functionality Process View Deployment View System engineering System integrators System topology, delivery, installation, communication Performance, scalability, throughput

Where Are We? What is modeling? Four principles of visual modeling The UML

What Is the UML? The UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a software-intensive system. Introduce the UML. Remember many of your students have no idea what the UML really is. The next four slides explain how the UML is a language for visualizing, specifying, constructing and documenting. The software systems that you develop today are more complex than the human mind can comprehend. This is why you model systems. Your model selection profoundly influences how you attack the problem and shape the solution. No single model is sufficient. Every complex system is best approached through a small set of nearly independent models. Therefore, to increase comprehension, a common language like the Unified Modeling Language (UML) is used to express models. A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language like the UML is a standard language for software blueprints.

The UML Is a Language for Visualizing
Essentials of Visual Modeling w/ UML Instructor Notes The UML Is a Language for Visualizing Communicating conceptual models to others is prone to error unless everyone involved speaks the same language. There are things about a software system you can’t understand unless you build models. An explicit model facilitates communication. Stress how the UML is designed to promote communication using pictures rather than text. Using the UML allows the “light bulb” to go on in the minds of many people. Rather than trying to interpret a textual description of a system design, the UML offers a graphical representation of that same description. In this case, a picture is truly worth a thousand words. Typically, projects and organizations develop their own language for modeling systems, making it difficult for outsiders and new team members to understand what is going on. Communicating these conceptual models to others is prone to error unless everyone involved speaks the same language. The UML offers a set of symbols that represents well-defined semantics. One developer can write a model in the UML, and another developer can interpret that model unambiguously. There are things about a software system you can’t understand unless you build models that transcend the textual programming language. For example, the meaning of a class hierarchy can be inferred, but not directly grasped, by staring at the code for all the classes in the hierarchy. The UML is a graphical language that addresses this problem. If the developer who cut the code never wrote down the models, the information would be lost forever. At best, the information would only be partially recoverable from the implementation after the developer has moved on. Writing models in the UML addresses this issue. An explicit model facilitates communication. (The Unified Modeling Language User Guide, Booch, 1999.)

The UML Is a Language for Specifying
Essentials of Visual Modeling w/ UML Instructor Notes The UML Is a Language for Specifying The UML builds models that are precise, unambiguous, and complete. The UML can be used to specify detailed or general models. Anyone who has worked on a project where miscommunication occurred appreciates this feature of the UML. The UML allows the modeler to specify their intentions in a clear, unmistakable manner. In this context, specifying means to build models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made to develop and deploy software-intensive systems. (The Unified Modeling Language User Guide, Booch, 1999.)

The UML Is a Language for Constructing
Essentials of Visual Modeling w/ UML Instructor Notes The UML Is a Language for Constructing UML models can be directly connected to a variety of programming languages. Maps to Java, C++, Visual Basic, and so on Tables in a RDBMS or persistent store in an OODBMS Permits forward engineering Permits reverse engineering The UML was designed with forward and reverse engineering in mind. Rational has partners who provide round-trip engineering for other languages. The UML is not a visual programming language. However, models using the UML can be directly connected to a variety of programming languages, making it possible to map from a model in the UML to a programming language or even to a database. If it is best expressed graphically, it is done graphically in the UML. If it is best expressed textually, it is done in the programming language. This mapping permits forward engineering: the generation of code from a UML model to a programming language. Reverse engineering is also possible: the reconstruction of a model from implementation back into the UML.

The UML Is a Language for Documenting
Essentials of Visual Modeling w/ UML Instructor Notes The UML Is a Language for Documenting The UML addresses documentation of system architecture, requirements, tests, project planning, and release management. UML diagrams should be treated as formal project artifacts. Each diagram created by a project team should be treated as an artifact. The UML can help alleviate some of the paper crunch that many software teams experience. Use Case Diagram Deployment Diagram Actor A Use Case 1 Use Case 2 Use Case 3 Actor B Window95 ¹®¼°ü¸® Å¬¶óÀÌ¾ðÆ®.EXE Windows NT ¹®¼°ü¸® ¿£Áø.EXE Windows95 Solaris ÀÀ¿ë¼¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌÅ¸º£ÀÌ½º¼¹ö ¹®¼°ü¸® ¾ÖÇÃ¸´ ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö Project artifacts are critical in controlling, measuring, and communicating about a system during its development and after its deployment. The UML addresses the documentation of a system’s architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management. (The Unified Modeling Language User Guide, Booch, 1999.) This slide does not represent all the diagrams defined in the UML specification. For example, there is no graphic presented here for a composite structure diagram or a timing diagram. Composite structure is a more advanced modeling concept that is not covered in this course. The timing diagram is new to UML2 and will be introduced in a later module. user mainWnd fileMgr : FileMgr repository document : Document gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) Æ¯Á¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù. ÈÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù. È¸é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡ º¸¿©ÁØ´Ù. GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) close( ) sortFileList( ) fillDocument( ) fList 1 FileList File read() fill the code.. Sequence Diagram Class Diagram

History of the UML UML 2.0 (2004) UML 1.5 (March, ‘03) UML Partners’ Expertise UML 1.1 (Sept. ‘97) UML 1.0 (Jan. ‘97) UML 0.9 (June ‘96) UML 0.91 (Oct. ‘96) and The UML 2.0 is defined by two complementary specifications, the Infrastructure and the Superstructure. The UML infrastructure defines foundational concepts that can be used in part or entirely by other specifications. The UML superstructure defines the complete UML. The superstructure specification is self contained and you won’t have to read the infrastructure specification unless you are concerned about configuring other specifications in parallel to UML. The UML metamodel (a description of a model) is divided into two main packages, structure and behavior with two supporting packages, auxiliary elements and profiles. • The structure package defines the static structure of the UML. The behavior package defines the dynamic structure of the UML. Each package is described by a chapter in the superstructure specification document. Public Feedback Unified Method 0.8 (OOPSLA ’95) Booch ’93 OMT - 2 OOSE Other Methods Booch ‘91 OMT - 1

Inputs to the UML Demonstrate that UML was developed as an industry standard with many influences. The UML is not owned and written by Rational. Do not spend a lot of time on this slide. Simply point out one or two contributors of special interest to your audience. For example, for a telephony audience, you might point out Harel and his state charts. Rumbaugh Booch Jacobson Meyer Fusion Before and after conditions Operation descriptions, message numbering Harel Embley State charts Singleton classes, High-level view Gamma, et.al UML development included incorporating ideas from numerous other methodologists. The main challenge was to construct an approach that was simple, yet allowed the modeling of a broad range of systems. The conceptual framework was established quickly, but the notational semantics took more time. Active collaboration with other industry leaders has brought unique expertise and experience into the UML effort. The UML effort was supported by a cross-section of the industry. Partners in the UML effort included HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software, Taskon, and Unisys. These partners provided contributors, reviewers, and advocates for the standardization efforts. In the end, a modeling language was created that has already withstood the test of widespread use in the industry and the scrutiny of international standardization efforts. Wirfs-Brock Frameworks, patterns, notes Responsibilities Shlaer- Mellor Selic, Gullekson, Ward Odell Object lifecycles ROOM (Real-Time Object-Oriented Modeling) Classification

IBM Software Group Essentials of Visual Modeling with UML 2.0 Class Diagrams

Objectives Describe the static view of the system and show how to capture it in a model. Demonstrate how to read and interpret a class diagram. Model an association and aggregation and show how to model it in a class diagram. Model generalization on a class diagram. Introduce the objectives for this module to the students.

Where Are We? Class diagrams Class relationships Association Aggregation Generalization The purpose of this section is to introduce, not teach everything about class diagrams. Remember, this is new to the students.

What Is a Class Diagram? Static view of a system Introduce class diagrams to the students. Interaction diagrams show the dynamic aspects of a system, while class diagrams show the static aspects of a system. CloseRegistrationForm + open() + close registration() Schedule - semester + commit() + select alternate() + remove offering() + level() + cancel() + get cost() + delete() + submit() + save() + any conflicts?() + create with offerings() + update with new selections() CloseRegistrationController + is registration open?() + close registration() Professor - name Student + get tuition() + add schedule() + get schedule() + delete schedule() + has pre-requisites() - employeeID : UniqueId - hireDate A class diagram shows the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system. Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information. The static view of a system primarily supports the functional requirements of a system. - status - discipline - maxLoad + submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()

Class Diagram Usage When modeling the static view of a system, class diagrams are typically used in one of three ways, to model: The vocabulary of a system Collaborations A logical database schema Set the context for this module and present some reasons for using class diagrams. Class diagrams are not entity-relationship diagrams. They go one step further with behavior. The database schema may not always match 1:1 with the class diagram, but they should be fairly close. Class diagrams allow you to model the vocabulary of your system when you determine the abstractions that are part of, or outside of, the boundaries of your system. Class diagrams specify these abstractions and their responsibilities. A collaboration is a grouping of classes and other elements that work together to provide a solution that is bigger than the sum of the elements in the collaboration. No class stands alone, but works in collaboration with other elements to carry out some sort of solution. Class diagrams are one way to model these collaborations. A database schema is similar to the blueprints for the conceptual design of a database. Many of the systems that you’ll design have persistent objects, which means that they have to be stored in a database for later retrieval. You can model schemas for these databases using class diagrams. The UML’s class diagrams are a superset of entity-relationship (E-R) diagrams. However, where typical E-R diagrams focus only on data, class diagrams take it one step further and allow the modeling of behavior, too. Behavior, modeled as operations, are generally turned into triggers or stored procedures on the database.

Example: Class Diagram
Essentials of Visual Modeling w/ UML Instructor Notes Example: Class Diagram Is there a better way to organize class diagrams? Provide an example of a class diagram. Ask: how many classes have you worked with on your largest project? Explain how difficult it can become to keep up with all of these classes. Offer examples from your own experience. LoginForm RegistrationController RegisterForCoursesForm Schedule CloseRegistrationForm CloseRegistrationController It’s not unusual for a system under development to contain hundreds, even thousands of different classes. Managing such large numbers generates its own problems. How can you organize classes and not lose the organization of the model? Professor Student Course CourseOffering CourseCatalogSystem BillingSystem

Review: What Is a Package?
Essentials of Visual Modeling w/ UML Instructor Notes Review: What Is a Package? A general purpose mechanism for organizing elements into groups. A model element that can contain other model elements. A package can be used: To organize the model under development As a unit of configuration management A package is really a “virtual bag.” You can place just about anything inside of it that you like. Packages allow us to organize our models into pieces that make sense. They support the OO concepts of hierarchy and modularity. A Package can be defined as: A general purpose mechanism for organizing elements into groups. (The Unified Modeling Language User Guide, Booch, 1999.) Models can have hundreds, even thousands, of model elements. The sheer number of these elements can quickly become overwhelming. It’s critical to group model elements into logical collections to keep the model manageable and readable. Packages are a generic mechanism for grouping elements into semantically related groups. A package contains classes that are needed by a number of different packages, but are treated as a “behavioral unit.” A package is simply a grouping mechanism. No semantics are defined for its instances. Thus, packages do not necessarily have a representation in implementation (except perhaps to represent a directory). In the UML, a package is represented as a tabbed folder. Package diagrams depict dependencies between packages and are now formalized in UML 2. University Artifacts

Example: Registration Package
Essentials of Visual Modeling w/ UML Instructor Notes Example: Registration Package Show the students how a package would look on a class diagram. Registration CloseRegistrationForm CloseRegistrationController These four classes - CloseRegistrationForm, RegisterForCoursesForm, CloseRegistrationController, and RegistrationController - have all been assigned to the Registration package because they are highly cohesive. RegisterForCoursesForm RegistrationController

Where Are We? Class diagrams Class relationships Association Aggregation Generalization The goal here is to introduce the students to some basic relationship types.

What Is an Association? The semantic relationship between two or more classifiers that specifies connections among their instances. A structural relationship specifying that objects of one thing are connected to objects of another thing. Introduce the concept of association to the students. This is new and may pose trouble for some students. There are also dependency relationships. However, dependencies are beyond the scope of this course since they are contingent on parameter, local variable or global reference. These topics are discussed in the Object-Oriented Analysis and Design course. For the beginner, understanding associations is enough. Draw these examples on the board as objects to help students understand the concept. Student An Association can be defined as: The semantic relationship between two or more classifiers that specifies connections among their instances. In other words, an association is a structural relationship that specifies that objects (instances of classes) of one thing are connected to objects of another thing. The way that you show these structural relationships between classes is through the use of associations. Associations are represented on class diagrams by a line connecting the associating classes. Data may flow in either direction or both directions across a link. Most associations are simple. That is, they exist between exactly two classes. They are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible. Sometimes, a class has an association to itself. This does not always mean that an instance of that class has an association to itself. More often, it means that one instance of the class has associations to other instances of the same class. This example shows that a student object is related to a schedule object. The second example demonstrates how a course object can be related to another course object. Schedule Course

Example: What Associations Can You Find?
Essentials of Visual Modeling w/ UML Instructor Notes Example: What Associations Can You Find? 1: submit schedule( ) 2: submit schedule( ) Have the students brainstorm what the class diagram looks like. One way to do this is to use the “whiteboard” to display the information that they find. Note: The reflexive message on the Schedule object does not mean that there is a reflexive association on the Schedule class. Also, the actor is not represented on the class diagram. The total number of associations that can be found on this slide are 5. The link between the actor and the Form is not an association and the reflexive message on Schedule does not indicate an association to self. . : RegisterForCoursesForm : RegistrationController : Student 8: any conflicts?( ) 3: save( ) 4: submit( ) : Schedule 7: still open?( ) 9: add student(Schedule) 6: has pre-requisites(CourseOffering) Using the information that you just learned, what do you think the class diagram representing this communication diagram looks like? : CourseOffering : Student 5: is selected?( ) 10: mark as enrolled in( ) : PrimaryScheduleOfferingInfo

What Is Multiplicity? Multiplicity is the number of instances one class relates to ONE instance of another class. For each association, there are two multiplicity decisions to make, one for each end of the association. For each instance of Professor, many Course Offerings may be taught. For each instance of Course Offering, there may be either one or zero Professor as the instructor. Introduce the concept of multiplicity. Multiplicity can be defined as: The number of instances one class relates to one instance of another class. For each role, you can specify the multiplicity of its class and how many objects of the class can be associated with one object of the other class. Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges. It is important to remember that multiplicity is referring to instances of classes (objects) and their relationships. In this example, a Course Offering object may have either zero or one Professor object related to it. Conversely, a Professor object may have zero or more Course Offering objects related to it. Multiplicity must be defined on both ends of the association. instructor Professor CourseOffering 0..1 0..1 0..* 0..*

Multiplicity Indicators
Essentials of Visual Modeling w/ UML Instructor Notes Multiplicity Indicators Unspecified Show the valid multiplicity indicators. The use of “N” instead of “*” is Booch, not UML (for example, the use of “0..N” and “N” is not UML). The multiplicity specified for a relationship is for all instances of that relationship, not simply for a particular use-case realization or for a particular point in time. Exactly One 1 Zero or More 0..* Zero or More * One or More 1..* Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges. A range is indicated by an integer (the lower value), two dots, and an integer (the upper value). A single integer is a valid range, and the symbol “*” indicates "many.” That is, an asterisk “*” indicates an unlimited number of objects. The symbol “*”by itself is equivalent to “0..*” That is, it represents any number including none. This is the default value. Optional value has the multiplicity 0..1. Zero or One (optional value) 0..1 Specified Range 2..4 Multiple, Disjoint Ranges 2, 4..6

Example: Multiplicity
Essentials of Visual Modeling w/ UML Instructor Notes Example: Multiplicity Provide the students with an opportunity to see how multiplicity can be interpreted from a class diagram. Here are the answers to the student notes questions. 1. There is an association relationship between each of the classes. RegisterForCoursesForm to RegistrationController has a lower and upper bound of 1. Schedule to CourseOffering is 0 (low) to 4 (high). CourseOffering to Schedule is 0 (low) to many (high). 2. A RegisterForCoursesForm instance is mandatory because it must be associated with exactly one instance of RegistrationController. 3. Zero to four. 4. One. 5. No, a schedule must be associated to one student. 6. For each RegisterForCoursesForm, there is one RegistrationController which has zero or one Schedule. 1 1 RegisterForCoursesForm RegistrationController 1 1 0..1 0..1 0..1 1 Describe the following relationships between: RegisterForCoursesForm and RegistrationController; Schedule to CourseOffering; and CourseOffering to Schedule. What is the lower and upper bounds for these relationships? Which relationships are mandatory? What do the mandatory relationships tell you about the different classes? How many course offerings can appear on a Schedule? How many students are assigned to each Schedule? Can a Schedule exist without a student? How many schedules can be open on a RegisterForCoursesForm? 0..* Student Schedule CourseOffering 0..* 0..4

Where Are We? Class diagrams Class relationships Association Aggregation Generalization

What Is an Aggregation? A special form of association that models a whole-part relationship between the aggregate (the whole) and its parts. An aggregation is an “is a part-of” relationship. Multiplicity is represented like other associations. Introduce the concept of aggregation to the students. Composition is not covered in this course. Composition is a stronger form of aggregation that indicates coincident lifetimes. An Aggregation can be defined as: A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts. Aggregation is used to model a whole-part relationship between model elements. There are many examples of whole-part relationships: a Library contains Books, Departments are made up of Employees, a Computer is composed of a number of Devices. To model an aggregation, the aggregate (Department) has an aggregation association to its constituent parts (Employee). A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation. An aggregation relationship that has a multiplicity greater than one for the aggregate is called shared. Destroying the aggregate does not necessarily destroy the parts. By implication, a shared aggregation forms a graph or a tree with many roots. Shared aggregations are used when one instance is a part of two other instances. So, the same instance can participate in two different aggregations. Whole 1 Part 0..1

Example: Aggregation Give the students an opportunity to see how aggregation can be interpreted from a class diagram. Have the students answer each of the questions in the student notes. Here are the answers to the student notes questions. 1. The Schedule to Student instance is an example of an aggregation. 2. Schedule is a part of the Student aggregate (whole). 3. This relationship is an aggregate because it has a multiplicity greater than one. It models a whole-part relationship. 1 1 RegisterForCoursesForm RegistrationController 1 1 0..1 0..1 0..1 1 Which relationship is an aggregation? How would you read this aggregate relationship? Why is this relationship an aggregate? 0..* Student Schedule CourseOffering 0..* 0..4

Where Are We? Class diagrams Class relationships Association Aggregation Generalization

Review: What Is Generalization?
Essentials of Visual Modeling w/ UML Instructor Notes Review: What Is Generalization? A relationship among classes where one class shares the structure and/or behavior of one or more classes. Defines a hierarchy of abstractions where a subclass inherits from one or more superclasses. Single inheritance Multiple inheritance Is an “is a kind of” relationship. Generalization relationships are also permitted between packages. However, packages do not have semantics. Therefore, generalization between packages is not common. Generalization among subsystems is practical. According to Grady Booch: The terms “inheritance” and “generalization” are, practically speaking, interchangeable. The UML standard is to call the relationship “generalization,” so as not to confuse people with language-specific meanings of inheritance. To confuse matters more, some call this an “is-a” or a “kind of” relationship (especially those into conceptual modeling in the cognitive sciences). So, for most users, it’s fair to use either term. For power users, people who care about things like the UML metamodel and specifying formal semantics of the same, the relationship is called “generalization” and applying such a relationship between two classes, for example, results in the subclass inheriting the structure and operations of the superclass (inheritance is the mechanism). Generalization can be defined as: A specialization/generalization relationship, in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). (The Unified Modeling Language User Guide, Booch, 1999.) The subclass may be used where the superclass is used, but not vice versa. The child inherits from the parent. Generalization is transitive. You can always test your generalization by applying the “is a kind of” rule. You should always be able to say that your specialized class “is a kind of” the parent class. The terms “generalization” and “inheritance” are generally interchangeable, but if you need to distinguish, generalization is the name of the relationship. Inheritance is the mechanism that the generalization relationship represents/models. Inheritance can be defined as: The mechanism by which more-specific elements incorporate the structure and behavior of more-general elements. (The Unified Modeling Language User Guide, Booch, 1999.) Single inheritance: The subclass inherits from only one superclass (has only one parent). Multiple inheritance: The subclass inherits from more than one superclass (has multiple parents).

Example: Single Inheritance
Essentials of Visual Modeling w/ UML Instructor Notes Example: Single Inheritance One class inherits from another. Demonstrate how generalization looks on a class diagram. This is the UML representation of generalization that was introduced earlier in the course. Ancestor Account - balance Superclass (parent) - name - number + withdraw() + createStatement() Generalization Relationship The generalization is drawn from the subclass class to the superclass/parent class. The terms “ancestor” and “descendent” may be used instead of “superclass” and “subclass.” Subclasses (children) Savings Checking Descendents

Example: Multiple Inheritance
Essentials of Visual Modeling w/ UML Instructor Notes Example: Multiple Inheritance A class can inherit from several other classes. Demonstrate how generalization looks on a class diagram. Some languages do not support multiple inheritance. This is the UML representation of generalization that was introduced earlier in the course. FlyingThing Animal Multiple Inheritance Airplane Multiple inheritance means that a class can inherit from several other classes. For example, Bird inherits from both FlyingThing and Animal. Multiple inheritance is conceptually straight forward and may be needed to model the real world accurately. However, there are potential implementation problems when you use multiple inheritance, and not all implementation languages support it. Thus, be judicious with your use of multiple inheritance. Use it only where it accurately describes the concept you are trying to model and reduces the complexity of your model. Be aware, however, that this representation probably needs to be adjusted in design and implementation. Generally, a class inherits from only one class. Helicopter Bird Wolf Horse Use multiple inheritance only when needed and always with caution!

IBM Software Group Essentials of Visual Modeling with UML 2.0 Interaction Diagrams

Objectives Describe dynamic behavior and show how to capture it in a model. Demonstrate how to read and interpret: A sequence diagram A communication diagram Explain the similarities and differences between communication and sequence diagrams. Introduce the objectives for this module.

Objects Need to Collaborate
Essentials of Visual Modeling w/ UML Instructor Notes Objects Need to Collaborate Objects are useless unless they can collaborate to solve a problem. Each object is responsible for its own behavior and status. No one object can carry out every responsibility on its own. How do objects interact with each other? They interact through messages. Set the context of the module so that the students understand why interaction diagrams are needed. Objects need to realize the behavior specified in each use-case scenario. How is this done? The objects must collaborate together to bring about the desired behavior in the system. Is there a mechanism that allows these objects to work together? There is, and that mechanism is called a message.

Objects Interact with Messages
Essentials of Visual Modeling w/ UML Instructor Notes Objects Interact with Messages A message shows how one object asks another object to perform some activity. Explain how objects “talk” to each other when they collaborate. Messages are used by objects in the same way that messages are used by people. For example, an air traffic controller can send a message to an airplane pilot that it is ok to land. The pilot then lands the airplane (responsibility). After the plane is on the ground, the pilot sends a signal back to the air traffic controller (return value) that they have finished landing. Message getCourseOfferings(forSemester) : Car buyer :RegistrationController A message can be defined as: The specification of a communication among objects that conveys information with the expectation that activity will ensue. (The Unified Modeling Language User Guide, Booch, 1999.) When you pass a message, the action that results is an executable statement that forms an abstraction of a computational procedure. An action may result in a change of state. Messages are the mechanism that permits objects to interact with each other. A message is often implemented by a simple activity. For example, one object calls an operation in another. When the activity has been executed, the control is returned to the caller along with a return value. :CourseCatalogSystem

What is an Interaction Diagram?
Essentials of Visual Modeling w/ UML Instructor Notes What is an Interaction Diagram? Generic term that applies to several diagrams that emphasize object interactions Sequence Diagram Communication Diagram Specialized Variants Timing Diagram Interaction Overview Diagram Introduce the concept of an interaction diagram for modeling object collaborations. Emphasize that interaction diagrams are used to model the dynamic aspects of a system. Static modeling is discussed in the class diagrams module. There is a tabular alternative to Interaction Diagrams in the UML 2 specification. It’s anticipated that there will be limited tool support for the tabular format so we don’t cover it.

Interaction Diagrams Sequence Diagram Time oriented view of object interaction Communication Diagram Structural view of messaging objects Sequence Diagrams The sequence diagram is a time-oriented view of the interaction between objects to accomplish a behavioral goal of the system. An interaction may be modeled at any level of abstraction within the system design, from subsystem interactions to instance-level interaction for a single operation or activity. The communication diagram is a structural view of the messaging between objects, taken from the Collaboration diagram concept of UML1. Communication Diagrams

Interaction Diagrams Timing Diagram Time constraint view of messages involved in an interaction Interaction Overview Diagram High level view of interaction sets combined into logic sequence The interaction overview diagram is a variety of an activity diagram incorporating sequence diagram fragments in place of actions and activities. Timing Diagrams Interaction Overview Diagrams The timing diagram is an optional diagram designed to specify the time constraints on messages sent and received in the course of an interaction. This diagram probably has more usefulness in real-time applications where timing is critical. The interaction overview diagram is a high-level view of the sets of interactions combined into logic sequence, including flow-control logic to navigate between the interactions. Think of this as a cross between a Sequence Diagram, for the interactions sets, and an Activity Diagram, for the logic sequence.

Where Are We? Sequence diagrams Communication diagrams Interaction diagram comparison The goal of this section is to introduce, not teach introductory topics about sequence diagrams.

What Is a Sequence Diagram?
Essentials of Visual Modeling w/ UML Instructor Notes What Is a Sequence Diagram? A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. The diagram shows: The objects participating in the interaction. The sequence of messages exchanged. Messages are executed in sequence and take place over a certain period of time. A sequence diagram describes a pattern of interaction among objects, arranged in a chronological order. It shows the objects participating in the interaction by their "lifelines" and the messages that they send to each other. In most cases, we use a sequence diagram to illustrate use-case realizations. That is, realizations show how objects interact to perform the behavior of all or part of a use case. One or more sequence diagrams may illustrate the object interactions that enact a use case. A typical organization is to have one sequence diagram for the main flow of events and one sequence diagram for each independent sub-flow of the use case. Sequence diagrams are particularly important to designers because they clarify the roles of objects in a flow and provide basic information for determining class responsibilities and interfaces. Sequence Diagram

Example: Sequence Diagram
Essentials of Visual Modeling w/ UML Instructor Notes Example: Sequence Diagram Have the students read through this diagram. Help them if they get stuck. The next few slides discuss the details of the items found on this diagram. Note: the purpose of this slide is to show how a sequence diagram fits together. There are no //’s because the // is a way to represent responsibilities. Responsibilities are discussed in the OOAD course but are outside the scope of this course. : Student :RegisterForCoursesForm :RegistrationController :CourseCatalogSystem : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(forSemester) 4: get course offerings( ) 5: display course offerings( ) You can have objects and actor instances in sequence diagrams, together with messages describing how they interact. The diagram describes what takes place in the participating objects, in terms of activations, and how the objects communicate by sending messages to one another. You can make a sequence diagram for each variant of a use case's flow of events. The above example shows the object interactions to support the Register for Courses’ use case, Create a Schedule sub-flow. Note the following responsibility allocation rationale. The RegisterForCoursesForm knows what data it needs to display and how to display it. It does not know where to go to get it. That is one of the RegistrationController’s responsibilities. Only the RegisterForCoursesForm interacts with the Student actor. The RegistrationController understands how Students and Schedules are related. Only the CourseCatalogSystem class interacts with the external legacy Course Catalog System. Note the inclusion of the actors. This is important as it explicitly models what elements communicate with the “outside world.” 6: display blank schedule( ) Select Offerings ref

Sequence Diagram Contents: Objects
Essentials of Visual Modeling w/ UML Instructor Notes Sequence Diagram Contents: Objects Explain objects on a sequence diagram. Make sure the students understand that this is an object diagram and not a class diagram. How do you know that these are objects and not classes? (The names are underlined.) :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem Anonymous Objects Named Object An object is shown as a vertical dashed line called the "lifeline." The lifeline represents the existence of the object at a particular time. An object symbol is drawn at the head of the lifeline, and shows the name of the object and its class underlined and separated by a colon: objectname : classname You can use objects in sequence diagrams in the following ways: A lifeline can represent an object. Thus, you can use a lifeline to model both class and object behavior. Usually, a lifeline represents all objects of a certain class. An object's class can be unspecified. Normally you create a sequence diagram with objects first and specify their classes later. The objects can be unnamed. However, name them if you want to discriminate different objects of the same class. Several lifelines in the same diagram can represent different objects of the same class. As stated previously, the objects should be named so that you can discriminate between the two objects. A lifeline that represents a class can exist in parallel with lifelines that represent objects of that class. The object name of the lifeline that represents the class can be set to the name of the class. Lifelines

Sequence Diagram Contents: Actor
Essentials of Visual Modeling w/ UML Instructor Notes Sequence Diagram Contents: Actor :RegisterForCoursesForm :RegistrationController SWTSU Catalog : Explain actors on a sequence diagram. Human actors usually initiate action and are on the left side of the sequence diagram. If an actor is a passive recipient of information, they are on the right side. Avoid placing an actor in the middle of a set of objects. CourseCatalogSystem : Student : Course Catalog Actor instances Normally an actor instance is represented by the first (leftmost) lifeline in the sequence diagram, as the invoker of the interaction. If you have several actor instances in the same diagram, try keeping them either to the leftmost or to the rightmost lifelines. Don’t show the interaction between actors in a sequence diagram because actors are, by definition, external to the system.

Sequence Diagram Contents: Messages
Essentials of Visual Modeling w/ UML Instructor Notes Sequence Diagram Contents: Messages :RegisterForCoursesForm :RegistrationController SWTSU Catalog : Explain messages on a sequence diagram. Reflexive messages are usually not public messages. Normally, these messages are private. Conversely, messages that are invoked from another object must be public. CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 4: get course offerings( ) A message is a communication between objects that conveys information with the expectation that activity will ensue. In sequence diagrams, a message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object. For a message from an object to itself, the arrow may start and finish on the same lifeline. The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often omitted in sequence diagrams, where the physical location of the arrow shows the relative sequence. A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message. (// is a way to represent responsibilities and is discussed further in the OOAD course.) It is not the name of an operation of the receiving object. You can later assign the message by specifying the operation of the message's destination object. The specified operation then replaces the name of the message. 5: display course offerings( ) 6: display blank schedule( ) Message Reflexive Messages

Sequence Diagram Contents: Execution Occurrence
Essentials of Visual Modeling w/ UML Instructor Notes Sequence Diagram Contents: Execution Occurrence :RegisterForCoursesForm :RegistrationController SWTSU Catalog : Explain execution occurrence on a sequence diagram. CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 4: get course offerings( ) The execution occurrence is a tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure. The top of the rectangle is aligned with the start of the action. The bottom is aligned with its completion. In earlier UML releases, the execution occurrence was called the focus of control. This changed with UML 2. 5: display course offerings( ) 6: display blank schedule( ) Execution Occurrence

Sequence Diagram Contents: Event Occurrence
Essentials of Visual Modeling w/ UML Instructor Notes Sequence Diagram Contents: Event Occurrence :RegisterForCoursesForm :RegistrationController SWTSU Catalog : Explain event occurrence on a sequence diagram. CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 4: get course offerings( ) The event occurrence is the sending or receipt of a message by an object. An event occurrence is not explicitly shown as a separate modeling concept. It is normally shown by the intersection of the message with the lifeline. A message connects two event occurrences on two lifelines. 5: display course offerings( ) 6: display blank schedule( ) Event Occurrence

Sequence Diagram Contents: Interaction Occurrence
Essentials of Visual Modeling w/ UML Instructor Notes Sequence Diagram Contents: Interaction Occurrence :RegisterForCoursesForm :RegistrationController SWTSU Catalog : Explain interaction occurrence on a sequence diagram. CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 4: get course offerings( ) The interaction occurrence is a reference to an interaction within the definition of another interaction. An interaction occurrence is shown in a sequence diagram as a rectangle with the tag ref (for reference). The rectangle covers the lifelines that are included in the referenced interaction. The name of the referenced interaction is placed in the rectangle 5: display course offerings( ) Interaction Occurrence 6: display blank schedule( ) Select Offerings ref

Where Are We? Sequence diagrams Communication diagrams Interaction diagram comparison The goal of this section is to introduce communication diagrams.

What Is a Communication Diagram?
Essentials of Visual Modeling w/ UML Instructor Notes What Is a Communication Diagram? A communication diagram emphasizes the organization of the objects that participate in an interaction. The communication diagram shows: The objects participating in the interaction. Links between the objects. Messages passed between the objects. Unlike sequence diagrams, communication diagrams emphasize the organization of the objects. Sequence diagrams, on the other hand, emphasize the time ordering of the messages. A communication diagram shows how objects interact to perform the behavior of a particular use case or a part of a use case. Like sequence diagrams, communication diagrams are used by designers to define and clarify the roles of the objects that perform a particular flow of events of a use case. They are the primary source of information used to determine class responsibilities and interfaces. Because of the communication diagram’s format, they tend to be better suited for analysis activities. Specifically, they tend to be better suited to depict simpler interactions of a smaller number of objects. As the number of objects and messages grows, the diagram becomes increasingly hard to read. It is also difficult to show additional descriptive information like timing, decision points, or other unstructured information that can be easily added to the notes in a sequence diagram. Communication Diagrams

Example: Communication Diagram
Essentials of Visual Modeling w/ UML Instructor Notes Example: Communication Diagram Provide a preview of a communication diagram for the students. Explain how communication diagrams allow you to see the communication patterns among the objects. Normally, boundary classes are on the “edge,” interfacing with actors. Control classes are toward the middle, managing communication. Entity classes are on the “bottom” where all of the persistent data lives. 5: display course offerings( ) 6: display blank schedule( ) 1: create schedule( ) : Course Catalog : RegisterForCoursesForm : Student 2: get course offerings( ) You can have objects and actor instances in communication diagrams, together with links and messages describing how they are related and how they interact. The diagram describes what takes place in the participating objects, in terms of how the objects communicate by sending messages to one another. You can make a communication diagram for each variant of a use case's flow of events. The above example shows the communication of objects to support the Register for Courses use case, Create a Schedule sub-flow. It is the “communication diagram equivalent” of the sequence diagram shown earlier. 4: get course offerings( ) 3: get course offerings(forSemester) : RegistrationController : CourseCatalogSystem

Communication Diagrams Contents: Objects
Essentials of Visual Modeling w/ UML Instructor Notes Communication Diagrams Contents: Objects Explain objects on a communication diagram. Make sure the students understand that this is an object diagram and not a class diagram. How do you know that these are objects and not classes? (The names are underlined.) Note: You don’t have to show the boundary, control, and entity stereotypes on a communication diagram, but they can help you see communication patterns quicker. : RegisterForCoursesForm Objects An object is represented by an object symbol, showing the name of the object and its class underlined, separated by a colon. objectname : classname You can use objects in communication diagrams in the following ways: An object's class can be unspecified. Normally, you create a communication diagram with objects first and specify their classes later. The objects can be anonymous. However, you should name them if you want to discriminate different objects of the same class. : RegistrationController SWTSU Catalog : CourseCatalogSystem

Communication Diagram Contents: Actors
Essentials of Visual Modeling w/ UML Instructor Notes Communication Diagram Contents: Actors Explain actors on a communication diagram. : RegisterForCoursesForm : Student : Course Catalog Actors Normally an actor instance occurs in the communication diagram as the invoker of the interaction. If you have several actor instances in the same diagram, try to keep them in the periphery of the diagram. Don’t show the interaction between actors in a communication diagram because actors are, by definition, external to the system. : RegistrationController SWTSU Catalog : CourseCatalogSystem

Communication Diagram Contents: Links and Messages
Essentials of Visual Modeling w/ UML Instructor Notes Communication Diagram Contents: Links and Messages Explain links and messages on a communication diagram. Point out that these are the same messages that were seen on the sequence diagram. Notice, however, that you have to follow the numbers to figure out the sequence. This diagram is more effective at pointing out the relationships between the objects. Messages 5: display course offerings( ) 6: display blank schedule( ) Links 1: create schedule( ) : Course Catalog : RegisterForCoursesForm : Student 2: get course offerings( ) A link is a relationship between objects across which messages can be sent. In communication diagrams, a link is shown as a solid line between two objects. An object interacts with or navigates to other objects through its links to these objects. A link can be an instance of an association. Or, it can be anonymous, meaning that its association is unspecified. Message flows are attached to links. A message is a communication between objects that conveys information with the expectation that activity will ensue. In communication diagrams, a message is shown as a labeled arrow placed near a link. That is, the link is used to transport or otherwise implement the delivery of the message to the target object. The arrow points along the link in the direction of the target object (the one that receives the message). The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often used in communication diagrams because they are the only way to describe the relative sequencing of messages. 4: get course offerings( ) 3: get course offerings(forSemester) : RegistrationController : CourseCatalogSystem

Where Are We? Sequence diagrams Communication diagrams Interaction diagram comparison

Sequence and Communication Diagram Similarities
Essentials of Visual Modeling w/ UML Instructor Notes Sequence and Communication Diagram Similarities Semantically equivalent Can convert one diagram to the other without losing any information Model the dynamic aspects of a system Model a use-case scenario Show the students the similarities between sequence and communication diagrams. Go back and point to the semantic similarities between the two diagrams. Because they both derive the same information from the UML’s metamodel; sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a diagram in one form and convert it to the other without any loss of information.

Sequence and Communication Diagram Differences
Essentials of Visual Modeling w/ UML Instructor Notes Sequence and Communication Diagram Differences Sequence diagrams Communication diagrams Show the explicit sequence of messages Show execution occurrence Better for visualizing overall flow Better for real-time specifications and for complex scenarios Show relationships in addition to interactions Better for visualizing patterns of communication Better for visualizing all of the effects on a given object Easier to use for brainstorming sessions Show the students the differences between the two diagrams. The use of sequence versus communication diagrams is a personal choice. This course does not recommend one over the other, but describes the advantages of each. For brainstorming, some find the communication diagram easier, a closer visual representation of CRC cards. The students should use the diagram they like best. However, you may want to recommend that they ultimately create the communication diagram to find relationships between the associated classes. Note: RUP recommends that communication diagrams be used in analysis and that sequence diagrams be used in design. Sequence and communication diagrams express similar information, but show it in different ways. Communication diagrams emphasize the structural communication of a society of objects and show a clearer picture of the pattern of relationships and control that exist among the objects participating in a use case. Communication diagrams also show more structural information, such as the relationships among objects. Communication diagrams are better for understanding all the effects of a given object and for procedural design. Sequence diagrams show the explicit sequence of messages and are better for real-time specifications and complex scenarios. A sequence diagram includes chronological sequences but does not include object relationships. Sequence numbers are often omitted in sequence diagrams, in which the physical location of the arrow shows the relative sequence. On sequence diagrams, the time dimension is easier to read, the operations and parameters are easier to present, and the larger number of objects are easier to manage than in communication diagrams. Both sequence and communication diagrams allow you to capture semantics of the use-case flow of events. They help identify objects, classes, interactions, and responsibilities, as well as validate the architecture.

IBM Software Group Essentials of Visual Modeling with UML 2.0 Other UML Diagrams

Objectives Demonstrate how to read and interpret a: State machine diagram Component diagram Deployment diagram Introduce the objectives for this module.

Where Are We? State machine diagrams Component diagrams Deployment diagrams The goal for this section is to introduce, not teach everything about state machines.

Review: An Object Has State
Essentials of Visual Modeling w/ UML Instructor Notes Review: An Object Has State State is a condition or situation during the life of an object, which satisfies some condition, performs some activity, or waits for some event. The state of an object normally changes over time. Review the definition of state. The state of an object is primarily defined through its attributes. In the next couple of slides, show the students that we will use the values of the Status attribute as a state in a state machine. The example of becoming a professor in the next slide is meant to explain how the state of an object changes over time. Name: J Clark Employee ID: HireDate: 07/25/1991 Status: Tenured Discipline: Finance MaxLoad: 3 The state of an object is one of the possible conditions that an object may exist in, and it normally changes over time. The state of an object is usually implemented by a set of properties called attributes, along with the values of the properties and the links the object may have with other objects. State is not defined by a “state” attribute or set of attributes. Instead, state is defined by the total of an object’s attributes and links. For example, if Professor Clark’s status changed from Tenured to Retired, the state of the Professor Clark object would change. Name: J Clark Employee ID: Date Hired: July 25, 1991 Status: Tenured Discipline: Finance Maximum Course Load: 3 classes Professor Clark

Example: Professor There are a sequence of events before an instructor becomes a University professor. Assistant professor (achieves tenure by producing a number of quality publications) Tenure/Associate professor Professor (based on seniority) Before an instructor becomes a University professor, they are first an assistant and then an associate professor. Each of these states or steps must satisfy some condition. The example of someone becoming a college professor serves us well in explaining how a state machine works. When you are hired for a teaching position at the university, you begin as an assistant professor. Based on your successful publication of numerous quality papers, you receive tenure and the title of assistant professor. There is not an automatic time line for becoming an associate professor, it is based on producing and publishing quality papers. However after you have tenure, seniority makes you available for the next available professorship.

What Are State Machine Diagrams?
Essentials of Visual Modeling w/ UML Instructor Notes What Are State Machine Diagrams? A state machine diagram models dynamic behavior. It specifies the sequence of states in which an object can exist: The events and conditions that cause the object to reach those states The actions that take place when those states are reached Introduce the concept of state machines. A state machine diagram shows a state machine, emphasizing the flow of control from state to state. Using the previous example, J. Clarke was an associate professor before she achieved tenure and became a full Professor. Another type of state machine that has been formalized in UML 2 is the Protocol State Machine. This is used to express usage protocols by defining rules on the invocation of operations or exchange of messages that a behavioral state machine or procedure may perform. This course does not cover these diagrams. A state machine diagram is typically used to model the discrete stages of an object’s lifetime. They show the sequences of state that an object goes through, the events that cause a transition from one state to another, and the actions that result from the state change. State machine diagrams are closely related to activity diagrams. Each state represents a named condition during the life of an object in which it satisfies some condition or waits for some event. A state machine diagram typically contains one start and multiple end states. Transitions connect the various states on the diagram. Like activity diagrams, decisions, and synchronizations may also appear on state machine diagrams. State machines are used to model the dynamic behavior of a model element, and more specifically, the event-driven aspects of the system's behavior. State machines are specifically used to define state-dependent behavior, or behavior that varies depending on which state the model element is in. Model elements whose behavior does not vary with the state, do not require state machines to describe their behavior. These elements are typically passive classes whose primary responsibility is to manage data. Assistant Professor Tenured

Special States The initial state is the state entered when an object is created. An initial state is mandatory. Only one initial state is permitted. The initial state is represented as a solid circle. A final state indicates the end of life for an object. A final state is optional. A final state is indicated by a bull’s eye. More than one final state may exist. Explain the need for start and final states. There is exactly one initial (start) state and 0..* final (end) states. To emphasize why an initial state is mandatory, ask the students to think about how they would read a diagram without an initial state. Note: Refer to the statement that “Only one initial state is permitted.” This is not always true. When you have nested states, there can be an initial state within each nested state AND the one outside of them. The initial state indicates the default starting place for the state machine or sub-state. An initial state is represented as a filled black circle. The final state indicates the completion of the execution of the state machine or the enclosing state. A final state is represented as a filled black circle surrounded by an unfilled circle. Initial and final states are actually pseudo-states. Neither may have the usual parts of a normal state, except for a name. Applied

What Are Events? An event is the specification of a significant occurrence that has a location in time and space. An event is an occurrence of a stimulus that can trigger a state transition. Example: Successful publication of numerous papers Explain events on a state machine. In the context of the state machine, an event can be defined as an occurrence of a stimulus that can trigger a state transition. Events may include signals, calls, the passing of time, or a change in state. A signal or call may have parameters whose values are available to the transition, including expressions for the guard conditions and action. It is also possible to have a triggerless transition, represented by a transition with no event trigger. These transitions, also called completion transitions, are triggered implicitly when their source state has completed its action. They are implicitly triggered on the completion of any internal ‘do activity’ in the state. Event Assistant Professor Tenured

What Are Transitions? A transition is a change from an originating state to a successor state as a result of some stimulus. The successor state could possibly be the originating state. A transition may take place in response to an event. Transitions can be labeled with event names. Explain transitions on a state machine. Transitions are not bi-directional. If transitions need to run both ways between two states, you can draw two different transitions going in opposite directions. A Transition can be defined as: A relationship between two states indicating that an object in the first state performs certain actions and enters a second state when a specified event occurs and specified conditions are satisfied. On such a change of state, the transition is said to “fire.” Until the transition fires, the object is said to be in the “source” state. After it fires, it is said to be in the “target” state. You can show one or more state transitions from a state as long as each transition is unique. Transitions originating from a state can not have the same event unless there are conditions on the event. The icon for a state transition is a line with an arrowhead pointing toward the destination state. Label each state transition with the name of at least one event that causes the state transition. You do not have to use unique labels for state transitions because the same event can cause a transition to many different states but it is recommended that they have unique labels. Assistant Professor Tenured maxPapers Transition Event Name

Example: State Machine
Essentials of Visual Modeling w/ UML Instructor Notes Example: State Machine Provide a sample state machine for the students to read. Briefly explain the advanced concepts of the state machine that are not covered in detail in this course. The Hired state is a composite state which means that it contains additional behavior inside the state. The H within a circle is known as a history pseudo state or a return to history. When the accepted transition reaches history of the Hired state, since we have never been here before we go to the initial pseudo state. The takeSabbatical transition is a group transition which means that any state inside of Hired can trigger this transition. When the return transition reaches history of the Hired state, we return to the state we were in last, i.e., if we were in the Tenured state when we took a Hiatus, we will return to the Tenured state upon reaching history. Hired Assistant Professor Applied accepted H maxPapers Tenured rejected seniority retired Professor H takeSabbatical return Hiatus

Where Are We? State machine diagrams Component diagrams Deployment diagrams

What Is a Component Diagram?
Essentials of Visual Modeling w/ UML Instructor Notes What Is a Component Diagram? A diagram that shows the organizations and dependencies among components Introduce the students to the concept of a component diagram. Interfaces and ports are covered in detail in DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0. ComponentA <<component>> ComponentB <<component>> Component diagrams commonly contain: Components Interfaces Realization, implementation and usage dependencies Classes Artifacts Ports You use component diagrams to model a static view of a system. There is no significant distinction between a component diagram and a general class diagram. Both are examples of structure diagrams which depict elements in a specification that are irrespective of time. Interfaces and ports are not covered in any detail in this course. Interfaces allow you to encapsulate, or hide, the implementation of a supplier. Ports are a structural notation used for interfaces. ComponentC <<component>> ComponentD <<component>>

What Is a Component? A modular part of a system that hides its implementation behind a set of external interfaces. Part of a logical or physical system It conforms to and provides the physical realization of a set of interfaces. It specifies the physical dependency to interfaces it requires. Introduce the students to the concept of a component. Explain to the students that the component notation is backwards compatible to UML 1.x. In UML 1.x, components were focused on the physical view. UML 2.0 has redirected this focus toward a more logical concept of a tightly encapsulated element so that they can be used in conceptual models. The distinction between a structured class and a component is somewhat vague and more a matter of intent than firm semantics. Structured classes are covered in DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0. Graphically, a component is shown as a rectangle with the keyword «component». Optionally, in the right hand corner, a component icon can be displayed. This icon is a small rectangle with two smaller rectangles protruding from its left hand side. The name of the component (as a type) is placed inside the outer rectangle. A component is 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. A component represents a modular piece of a logical or physical system. Components satisfying the same interfaces may be freely substituted. <<component>> Component Name ComponentName Required Interface Name Provided Interface Name

Where Are We? State machine diagrams Component diagrams Deployment diagrams

What Is a Deployment Diagram?
Essentials of Visual Modeling w/ UML Instructor Notes What Is a Deployment Diagram? The deployment diagram shows: Configuration of processing nodes at run-time Communication links between these nodes Deployed artifacts that reside on them Introduce deployment diagrams to the students. Remember, this is new to them. The purpose of the deployment diagram is to capture the configuration of processing elements, and the connections between processing elements in the system. The deployment diagram consists of one or more: Nodes (processing elements with at least one processor and memory) Connectors between nodes and/or devices The deployment diagram also maps processes on to these processing elements, allowing the distribution of behavior across nodes to be represented.

What Is a Node? Represents a run-time computational resource Generally has at least memory and often processing capability. Types: Device Physical computational resource with processing capability. May be nested Execution Environment Represent particular execution platforms Explain a node on a deployment diagram. <<device>> Device Name <<device>> Sub Device Name The essential elements of a deployment diagram are nodes and their connectors. A node is a run-time physical object that represents a computational resource, generally having at least memory and often processing capability as well. Execution Environment and device are types of node but the UML2 distinction between them is rather vague. Devices may have artifacts deployed for execution software that controls the functionality of the device itself (physical computational resource with processing capability). Typical examples include <<print server>>, <<application server>>, <<client workstation>>, <<mobile device>>, <<embedded device>>, <<processor>>, etc. Devices may be complex and contain other devices. Execution Environments represent particular execution platforms, such as an operating system (<<Win2K>>, <<VxWorks>>, etc.), a workstation engine (<<workstation engine>>), a database management system <<DB2>>), etc. <<exe env>> EE Name

What Is a Connector? A connector represents a: Communication mechanism Physical medium Software protocol Explain a connector on a deployment diagram. <<client workstation>> Kiosk <<100-T Ethernet>> Connectors can be drawn between nodes. These connectors represent communication mechanisms and can be described by physical mediums (for example, Ethernet, fiber optic cable) or software protocol (for example, TCP/IP, RS-232). A stereotype may be used to specify the type of connector. <<application server>> Server Connector <<RS-232>> <<client workstation>> Console

Example: Deployment Diagram
Essentials of Visual Modeling w/ UML Instructor Notes Example: Deployment Diagram <<client workstation>> PC Provide an example of a deployment diagram for the student to read. <<Campus LAN>> 1 <<application server>> Registration Server 1 <<Campus LAN>> <<Campus LAN>> 1 Deployment diagrams show the configuration of run-time processing nodes. A deployment diagram may be at the class or instance level. Deployment diagrams allow you to capture the topology of the system nodes. This allows you to visually see potential bottlenecks. A deployment diagram contains nodes connected by associations. The associations indicate a communication path between the nodes. The above diagram illustrates the deployment view for the Course Registration System. There are PC client workstations on the campus network. The main business processing hardware is the Registration Server. It talks to the two machines that host the legacy systems. All nodes are on the campus network. 1 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System

Example: Deployment Diagram with Processes
Essentials of Visual Modeling w/ UML Instructor Notes Example: Deployment Diagram with Processes <<client workstation>> PC Provide an example of a deployment diagram for the student to read. StudentApplication <<Campus LAN>> 1 <<application server>> Registration Server 1 CourseCatalogSystemAccess CourseRegistrationProcess BillingSstemAccess 1 <<Campus LAN>> <<Campus LAN>> The above diagram illustrates a refined deployment view for the Course Registration System. There are PC client workstations on the campus network. Each running a StudentApplication process. The main business processing hardware is the Registration Server running the CourseCatlogSystemAccess, CourseRegistrationProcess, and BillingSystemAccess processes. The Registration Server talks to the two machines that host the legacy systems. All nodes are on the campus network. 1 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System

Essentials of Visual Modeling w/ UML Instructor Notes

Similar presentations

Presentation on theme: "Essentials of Visual Modeling w/ UML Instructor Notes"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Essentials of Visual Modeling w/ UML Instructor Notes

Similar presentations

Presentation on theme: "Essentials of Visual Modeling w/ UML Instructor Notes"— Presentation transcript:

Similar presentations

About project

Feedback