Week 11: UML Overview IFS410: UML Models Spring 2007 In this module, basic concepts and brief outline for UML are explained. You have learned, or are learning or are going to learn, some materials in OO technology. For instance, Visual Basic utilizes the object-oriented programming concept; JAVA and C++ are examples of OOPL (object-oriented programming languages); and some conceptual reference to the OODBMS in the advanced database class. Although the interests of hiring industries for systems specialists in this area is very high, I don’t think it is not yet time to completely convert to OO techniques in the systems analysis and design field. Technical requirements (desirable skills) for Information Systems graduates are still in structured analysis and design, data flow diagrams, data modeling. Yet, more and more interviewing people are expressing their interest in students who has OOD skills, which NKU graduates fell behind UC graduates a little, but not far behind. The intention of this module is therefore, to invite you to experience the world of OOA and OOD so that you have pointers as to where to look for necessary information to explore the new world. I would not be surprised, if OOA and OOD are taught in IFS310 and/or 410 when you come back to school for another degree. Spring 2007

UML UML (Unified Modeling Language). UML is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML provides the precise notation that we need when modeling software systems. The UML is an open standard controlled by Object Management Group (OMG), rather than any one individual or company. Right now, the newest version is 1.4 and the next major release of UML, 2.0, is expected sometime in 2002. 3/20/2007

Figure 1: UML Models using Use-Case Driven Approach (Rosenburg, 1999) Again, Figure 1is the big picture that shows the key elements of the UML. The approach evolved from an application of theory presented by Booch, Rumbaugh, and Jacobson. Most of activities are iterative and incremental. The object-modeling approach in a Nutshell (Page-Jones, 2001): Identify your use cases using use case models. Identify your real-world domain objects and the generalization and aggregation relationships among those objects (domain model or object model). Start drawing a high level class diagram. If it’s feasible, do some rapid prototyping of the proposed system. Or gather whatever substantive information you have about the legacy system you are reengineering. Use a state diagram to show the real-time behavior Perform robustness analysis for each use case scenario (activity diagram and collaboration diagram). Update your domain model / class diagram with new objects and attributes as you discover them. (Analysis Phase Complete) Identify the messages, draw a sequence diagram with use case text running down the left side and design information on the right. Finish the class diagram by adding detailed design information (e.g., visibility values and patterns). (Design Phase Completed). Figure 1: UML Models using Use-Case Driven Approach (Rosenburg, 1999) 3/20/2007

Static Modeling: Class Diagram The Class Diagram shows classes’ single or multiple inheritance hierarchies and classes’ other interconnections via the association, composition, and aggregation constructs. Jim Rumbaugh defines a class as a description of a group of objects with similar properties, common behavior, common relationships, and common semantics. The first thing you need to do I building a static model of your system is to find appropriate classes that accurately represent the real abstractions the problem domain presents. The best sources of classes are likely to be: The high level problem statement Lower-level requirements Expert knowledge of the problem space Once domain model were identified, it will be the dictionary of terminology used in the project and the basis for the class model. The following is a typical steps to develop a class model: Build Generalization Relationships Build Associations between Classes Develop Association Classes (Link Classes) – much like an associative class Develop Aggregation/Component Classes (Optional) Draw an Analysis-Level Class Diagram Continue to Iterate and Refine 3/20/2007

Class Diagram 3/20/2007 Figure 3 Registration and Title class diagram The figure above is an UML class diagram for the Registration and Title. The model also reflects the object class associations and multiplicity. It would quite easy to imagine a few IS A relationships. For example, a Vehicle may actually either a trailer or a powered vehicle, which in turn was specialized into a car, truck, or a motorcycle. An owner in this system owns at least one vehicle but may owns up to infinite number of vehicles. The relationship between the owner and each of the vehicle he/she owns is represented by another class, Registration, which has a one-to-one relationship with a plate and a sticker. 3/20/2007

Dynamic Modeling: Use Case Model Use case modeling breaks down the entire scope of system functionality into many smaller statements of system functionality called use cases or business events. A use case: a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task. The concept of a use case is similar to that of a process in Data Flow Diagrams (DFDs). Usually a use case is very small behavior that makes up a task all together. 3/20/2007

Use Case Model 3/20/2007 Figure 5: Use case model composition The use case model includes the actors, the system, and the use cases themselves. The set of functionality of a given system is determined through the study of the functional requirements of each actor, expressed in the use cases in the form of 'families' of interactions . Actors are represented by little stick people who trigger the use cases, which are represented as ellipses contained within the system. An actor represents a role played by a person or a thing that interacts with a system. Actors are determined by observing the direct users of a system those who are responsible for its use or its maintenance as well as the other systems that interact with the one under study. The same physical person may play the role of several actors (vendor, client). Additionally, several people may all play the same role and therefore act as the same actor (all the customers). The name of the actor describes the role played by the user. 3/20/2007

Activity Diagrams Shows the conditional logic for the sequence of system activities needed to accomplish a business process Clearly shows parallel and alternative behaviors Can be used to show the logic of a use case An Activity diagram is a UML diagram that shows all of the flows of events for a use case in one place. To accomplish this, activity diagrams show different activities that the system performs and how different results cause the system to take different paths. Also, sometimes, it depicts the activities required to be performed in different places (e.g., departments). 3/20/2007

Activity Diagram For many people looking at the latest version of the UML, the most unfamiliar diagram is the new activity diagram. This is particularly unfamiliar since it is a diagram that was not present in works of either Booch, Jacobson, or Rumbaugh. In fact it is based upon the event diagram of Odell, although the notation is very different to that in Odell's books. The activity diagram focuses on activities, chunks of process that may or may not correspond to methods or member functions, and the sequencing of these activities. In this sense it is like a flow chart. It differs, however, from a flow chart in that it explicitly supports parallel activities and their synchronization. In the diagram above we see the find class activity triggers both the check prerequisite and the check permission activities. Indeed these checks will be done for each of the classes entered if required. Thus, if there are three classes that require prerequisite checks, there will be three threads on these activities. These threads, together with other threads without prerequisite nor permission started by the find class activity, are synchronized before the registration is dispatched. Action states: Action states represent the noninterruptible actions of objects. Action Flow: Action flow arrows illustrate the relationships among action states. 3/20/2007

Interaction Diagrams Interaction diagrams are models that describe how a group of objects collaborate in some behavior - typically a single use-case. Interaction diagrams come in two forms, both present in the UML: Sequence diagram and communication (collaboration) diagram The interaction diagrams show a number of example objects and the messages that are passed between these objects within the use-case. One of the great strengths of an interaction diagram is its simplicity. It is difficult to write much about interaction diagrams because they are so simple. They do, however, have weaknesses, the principal one is that although they are good at describing behavior: they do not define it. They typically do not show all the iteration and control that is needed to give an computationally complete description. Various things have been done to try and remedy this in the UML. 3/20/2007

A Sequence Diagram The diagram above shows a sequence diagram in Visio notation. The sequence of messages is indicated by reading down the diagram. 3/20/2007

Other Types of Diagrams in UML Object Models/Domain Models Robustness Diagram (Not UML 2) State (Chart) Diagram Component Diagram Deployment Diagram 3/20/2007

UML Project (Spring 2007) The project will be similar to a real-world development project. However, with limitation in schedule, the following models should be created (in order): 1. Use case diagram 2. Initial class diagram 3. Activity diagram 4. Sequence diagram 5. Refined class diagram 3/20/2007