Modeling with UML

New Version for Fall 2014

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 2.
2. Martin Fowler, "UML Distilled, A Brief Guide to the Standard Object Modeling Language", Third Edition.

Overview and Foundational Concepts

• A model is an imperfect representation of something. ( If it were perfect it would be a copy, not a model. )
• A view is a selected aspect of a model.
• Sample models of an airplane might include wiring diagrams, a flight simulator, a sketch of the instrument control panels, or a balsa wood model used for wind-tunnel testing. Economic models may conist of spreadsheets of measured and predicted values. A view may show details of wiring the GPS sensors to avoid interference from other electronics.
• Software engineers use models in two very important areas:
  1. Modelling the application domain, i.e. the relevant business environment, to better understand the world in which the system needs to operate, and how it will be used and integrate into the cusomer's business when completed.
  2. Modelling the solution domain, to plan out and discuss the proposed solution before it is implemented.

  

• The Unified Modeling Language is a standard tool used by software engineers and developers to communicate about software systems, much as architects use blueprints to communicate details of building construction.
• The majority of UML centers around diagrams and drawing convention, but there some other tools in UML besides drawings. ( E.g. use-cases. )
• Like all tools, there is some flexibility in the use of UML. However for effective communications it is important that all members of a communication ( e.g. all members of a team or a project ) agree upon the conventions being used.
• For this course we will standardize on the notation described in UML Distilled, Third Edition and other details from Bruegge and DuToit.
• Notes are indicated by a folded corner, and can be applied to any UML diagram:

Scenarios, Use Cases, and Their Diagrams

• Scenarios and use cases are both means of describing how the system will be used in a particular instance or circumstance.
• The literature is not always clear on the distinction between scenarios and use-cases, and some texts use the two term interchangeably.
• For this class, scenarios will be somewhat informal narratives, or stories, describing how the system is to be used. For example:

  Monthly Reports:  At the end of every month Mary has to generate the monthly reports, and distribute copies to all the managers and sub-managers.  The first thing she has to do is to make sure that all the end-of-the-month tests have been run, and that everyone else is logged off of the system.  Then she selects the date range and the specific information she wants included in her reports, selects either the long or short format, and selects a printer.  Depending on how busy the month has been, it may take as long as fifteen minutes, during which time no one else can use the system.  She only prints one copy on the computer, and then makes all the rest of the copies she needs on the copy machine.

• Use cases are more formal, with defined sections and a specific format:
  • Every use case ( and every scenario ) must have a name by wich it may be referred.
  • Participating "actors" indicate what external entities interact with the system during this use case.
    • Use cases are always initiated by some external actor, which should be indicated in the use case description. If an event occurs automatically on a regular schedule, then "time" may be listed as the initiating actor. Note that "actors" include any external entities that interact with the system, not just humans.
  • Entry condition indicates thet state the sytem is in prror to the use-case starting.( Precondition may be a better term. )
  • The flow of events lists the specific steps that occur during the use-case.
    • The initiating actor should perform the first step in the flow of events.
    • The steps should normally alternate between actor(s) and the system, with a cause-and-effect relationship between the actor's actions and the system's response.. An actor does something and the system responds, then the actor does something else and the sytem responds to that, and so on.
    • It is helpful to indent the actions taken by the system, to distinguish them from the actions taken by the external actors.
  • Exit condition indicates the state the system is in after the use-case concludes. It does not indicate the condition that causes the use case to exit. ( Postcondition may be a better term. )
  • Other sections may also be included, as needed.

  

• Use case diagrams show a diagrammatical "list" of the use-cases defined for a system, the relationaships between them ( if any ), and which external actors are involved in each use-case.
• Some authors use stick figures for all external actors, whether they be human or not. Others use different images for different external actors.
• The system boundary distinguishes between use-cases which are part of the system and external actors, which are not.
• When the number of use-cases in a system is more than a few, it may be better to break them up into several diagrams, each containing a related group of use-cases. ( See figure 2-45 below, under package diagrams. )

• Several kinds of relationships can be shown betwen related use-cases:
  • The << includes >> relationship is used when one normal commonly-occuring use case includes the actions of another normal commonly-occuring use-case. For example in an ATM application the WithdrawMoney use case might include the CheckBalance use case.
  • The << extends >> relationship is used mostly when an unusual or exceptional use-case complicates a normal one. For example in a sales application the MagneticStripeUnreadable use-case might extend the MakeSale use-case by requiring the salesperson to enter the customer's credit card information manually, including the 3-digit security code on the back.
  • The specialization ( inheritance ) relationship can also be indicated, when one use-case is a specialization of another. ( See class diagrams below. )

  

  

  

  • Use case relationship can also be indicated textually:

  

  

  

Sequence & Communication Diagrams

• Sequence Diagrams outline the steps that specific objects / classes take during the execution of a particular use-case.
• The vertical axis is time, with the beginning of the use-case at the top of the diagram.
• Each column corresponds to a particular actor, class, or object. Entities that existed at the beginning of the use-case are listed at the top, and entities that come into existence during the course of the use-case are listed at the point where they are created. Objects are underlined to distinguish them from classes.
• When an entity is active it is represented by a vertical bar. Otherwise it is represented by a dashed line.
• Some authors draw the return arrow in all cases. Others only when the return is significant or has some special features to be documented.

• Sections of sequence diagrams can be modified with repeating loops, alternative cases, or optional components:

• According to Bruegge and DuToit, the first column of a sequence diagram should always be the actor that initiates the use-case, the second should always be the boundary object that the actor interacts with, and the third should be the control object that controls the use-case.
  • Boundary objects represent user interfaces, such as menus and dialog boxes.
  • Control objects contain logic for controlling the order of events.
  • Entity objects represent tangible things or concepts in the application domain.
  • These concepts will be more fully explained in Chaper 5 of Bruegge & DuToit.

• Communication Diagams present the same information as sequence diagrams, in a more compact form.
• The order of operations is indicated by sequential numbers on the messages between objects.

Class Diagrams for System Design

• During system design the focus is on which classes exist, what are the overall responsibilities of each class, ( how do they work together ), and the relationships between them.
• Internal details of classes are not shown at this stage of development.

• One particularly important relationship is the inheritance / specialization relationship, indicated by a hollow ( usually equilateral ) triangle:

• Other associations can be labelled with roles, multiplicity information, or other qualifiers:

• Aggregation and composition relationships are also very important in sotware design.
  • Aggregation indicates a collection of items which exist independent of the containter they are in, such as groceries in a bag.
  • Composition indicates a collection of parts that make up a whole, and which do not exist independently of the whole, such as ingredients in a cake.

• Note that in some cases two classes may be related in more than one way. This is very important, for example, in the Composite design pattern:

• A simple line between two classes can be interpreted as either bidirectional access or undefined access. Unidirectional access can be specified by placing an arrow head on the connecting line.
• A dashed line indicates a dependency relationship between two classes, ( i.e. one depends on the other ), without a direct link between them.
• Qualified associations are best explained by example.

• Association classes contain information describing the relationship between two other classes. They can be illustrated ( and implemented ) in two different ways:

Grouping: Package and Deployment Diagrams

• Package diagrams are used to bundle items together, such as classes within a subsystem.
• Depending on the level of detail desired, the internal workings of the packages may or may not be shown.
  • When the internal contents are shown, relationship may be illustrated either to the package as a whole or to interior components..

• Components are like packages, with well defned interfaces that other componets can connect to. They are indicated by the component symbol, a box with defined input and output ports.
• The ball and socket notation indicates the services / interfaces that a component provides ( ball ) and requires ( socket. ) In theory any component that provides a particular interface can satisfy any other component that reqires that interface, with components being interchangeable so long as the interfaces match.

• Deployment diagrams document on what platform various components are deployed, where "platform" usually means hradware but can also mean software, such as an operating system:

Detailed Class Diagrams for Object Design

• In the object design phase the internal details of each class must be specified.
• In general internal details and relationships between classes and not shown on the same diagrams, unless the number of classes involved is small and the relationships between fields and methods of the classes involved is important.
• There are typically 3 sections in a detailed class diagram, showing the name, attributes, and methods of the class respectively.
  • On occasion either the attributes or methods sections may be empty.
  • Some designers will add additional sections beyond the standard three, for notes, references, test specification, or other information. Such additional sections are rare and non-standard.

Activity and State Diagrams for Modeling Actions

Role Playing with CRC Cards

• Class, Responsibility, Collaboration cards can be used by groups of programmers to act out a scenario, determining the responsibilities of each class and the other classes with which it collaborates as the role playing progresses.