System Models III: Luca Viganò

System Models III
Luca Vigan
Dipartimento di Informatica Universit di Verona
Ingegneria del SW, 06.04.11
Luca Vigan (Universit di Verona)
System Models III
1 / 118
Objectives of system modeling
To explain why the context of a system should be modeled as part of the requirements engineering process. To describe behavioral modeling, data modeling, and object modeling. To introduce some of the notations used in the Unied Modeling Language (UML). Today we will focus on Class Diagrams.
System Models III
2 / 118
Table of contents
1
Class diagrams Basic denitions and concepts Relations From Use Cases to objects
Procedure I: textual analysis Procedure II: CRC cards Different kinds of objects
2 3 4 5
Conclusions References Homework Appendix: The Object Constraint Language OCL
System Models III
3 / 118
The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
System Models III
4 / 118
UML: Overview (cont.)
Use Case diagrams: requirements of a system. Class diagrams: structure of a system. Interaction diagrams: message passing. Sequence diagrams. Collaboration diagrams. State and activity diagrams: actions of an object. Implementation diagrams: Component model: dependencies between code. Deployment model: structure of the runtime system. Object constraint language (OCL).
System Models III
5 / 118
Requirements Engineering: Overview
System Models III
6 / 118
Modeling example: object modeling
System Models III
7 / 118
Object models
Object models describe the system in terms of object classes and their associations. An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object. Various object models may be produced: Inheritance models. Aggregation models. Interaction models.
System Models III
8 / 118
Object models (cont.)
Natural ways of reecting the real-world entities manipulated by the system. More abstract entities are more difcult to model using this approach. Object class identication is recognized as a difcult process requiring a deep understanding of the application domain. Object classes reecting domain entities are reusable across systems.
System Models III
9 / 118
Inheritance models
Relationships between object classes (known as associations) are shown as lines linking objects. Organize the domain object classes into a hierarchy. Classes at the top of the hierarchy reect the common features of all classes. Object classes inherit their attributes and services from one or more superclasses. These may then be specialized as necessary. Inheritance is referred to as generalization and is shown upwards rather than downwards in a hierarchy. Class hierarchy design can be a difcult process if duplication in different branches is to be avoided.
System Models III
10 / 118
For example: Class models (High-Level)

Emphasis: objects and relationships. Goal: clarity and reusability. Objects are grouped into classes depending on their attributes and methods.
(House) House type: Land house Owner: P. Rossi Address: Caselle Area: 400 [qm] # baths: 3 Pool?: Yes Garten: 5000[qm] Year built: 1976 Sales price: 1.5 Mio.[Euro] Ask sales price
(House) House type: Bungalow Owner: G. Bianchi Address: Lazise Area: 250 [qm] # baths: 2 Pool?: No Garten: 1500[qm] Year built: 1986 Sales price: 1 Mio.[Euro] Ask sales price
(House) House type: City house Owner: G. Verdi Address: Verona Area: 200 [qm] # baths: 2 Pool?: No Garten: 400[qm] Year built: 1990 Sales price: .8 Mio.[Euro] Ask sales price
Class hierarchy formalizes inheritance, expresses shared attributes/methods. Generalizes ERAs.

House House type Area # baths Pool? Garten
Property Owner Address Year built Sales price Ask sales price
Buro # buro rooms # floors Elevator? Parking Garage? Ask # rooms
System Models III
11 / 118
Objectives of todays lecture
We continue our study of semi-formal specication languages. Today: UML Class Diagrams.
Denition, motivation, application area. Variants and extensions.
Goal: gain insight into this popular, semi-formal modeling language and its application to modeling static, structural aspects of systems.
System Models III
12 / 118
Class diagrams
Outline
1
2 3 4 5
System Models III
13 / 118
Class diagrams
Basic denitions and concepts
In object-oriented modeling, objects are the main unit of abstraction.

Used for modeling requirements, design, and implementation.
In an object-oriented model:
Objects carry out activities. Interface to objects is event oriented. Example: A robot has sensors, actuators, control units, etc.
Comparison: functional decomposition.

Decomposition of problem into functions (rather than activities). Interface is data-oriented (input/output of functions). Example: A compiler has a parser, code generator, ...
System Models III
15 / 118
Class diagrams
Denitions and concepts (cont.)

One interacts with objects. An object has: State: Encapsulated data. Consists of attributes or instance variables. Part of the state can be mutable. Behavior: An object reacts to messages by changing its state and generating further messages. Identity: An object is more than a set of values and methods. It has an existence and a name. An interface denes which messages an object can receive.
It describes behavior without describing implementation or state. Often one differentiates between public interfaces, which all objects can use, and private interfaces, which (only) the object itself can use.
An example: a watch interface (+ denotes public) + reportTime() : Time + resetTimeTo(newTime:Time)

Luca Vigan (Universit di Verona) System Models III Ingegneria del SW, 06.04.11 16 / 118
Class diagrams
Denitions and concepts (cont.)

A class describes objects with similar structure and behavior. class Point { int x = 0, y = 0; void move(int dx, int dy)
x += dx; y += dy;
A class has a xed interface and denes attributes and methods. Advantages of classes. Conceptual: Many objects share similarities (e.g. the 10,000+ bank customers). Implementation: Only one implementation. Further advantages: (to be presented later)
Inheritance or overriding of methods. Dynamic binding, where method implementations are determined at run-time.
Class diagrams
Todays topic: Class diagrams

Language to model the static view of a system. A class diagram describes the kind of objects in a system and their different static relationships. Kinds of relationships include Associations, e.g. can a customer rent videos? Subtypes, e.g. is a nurse a person? Central model of object oriented analysis with the largest applicability. Generalizes other kinds of static modeling languages, e.g. ERA diagrams
A R B
System Models III
18 / 118
Class diagrams
First an example
Order
dateReceived isPrepaid number : String price : Money dispatch() close() 1 Generalization {if Order.customer.creditRating is "poor", then Order.isPrepaid must be true} Constraint Class Multiplicity
Customer *
Association 1 name address creditRating():String
Corporate Customer
contactName creditRating creditLimit remind() billForMonth(Integer)
Personal Customer
creditCard# {creditRating()== "poor"}
Attributes Role Name
Operations
line items
* *
sales rep 0..1
Order Line
quantity : Integer price : Money isSatisfied : Boolean
Employee
Product
System Models III
19 / 118
Class diagrams
Reasons for using class diagrams
Conceptual: Represent concepts in application domain. Independent of an implementation. Specication: Specify interfaces and give hints to the semantics. Implementation: Describe what must be implemented. UML does not distinguish between these uses! Class diagrams may be employed for different purposes. Example: in requirements modeling one omits many details. Decisions like where state and behavior are localized, how one navigates between objects, etc., are given later in development models.
System Models III
20 / 118
Class diagrams
What are classes?
A class describes a set of objects with equivalent roles in a system. Examples: Tangible, real-world things: Airplanes, computers, beer kegs, ... Roles: Library member, student, teacher, ... Business things: Orders, accounts, ... Application things: Power-on buttons, ... Data structures: Lists, hash-tables, ...
System Models III
21 / 118
Class diagrams
Visual representation of classes

A class is represented as a square, with optional attributes and operations.
A class encapsulates state (attributes) and behavior (operations):

Attributes dene the state (data values) of the object. Each attribute has a type. Operations (or methods) dene how objects effect each other. Each operation has a signature.
Class name is the only mandatory information.
System Models III
22 / 118
Class diagrams
Class diagrams
Class diagrams represent the structure of the system. Used
during requirements analysis to model application domain concepts, during system design to model subsystems, during object design to specify the detailed behavior and attributes of classes.
System Models III
23 / 118
Class diagrams
Instances (objects)
System Models III
24 / 118
Class diagrams
Actor vs. class vs. object

Actor: An entity outside the system to be modeled, interacting with the system (Passenger). Class: An abstraction modeling an entity in the application or solution domain. The class is part of the system model (User, Ticket distributor, Server). Object: A specic instance of a class (Joe, the passenger who is purchasing a ticket from the ticket distributor).
System Models III
25 / 118
Class diagrams
Attributes
The full syntax for an attribute is
visibility name : type multiplicity = default {property-string}
e.g. : - name:
String [1] = Untitled {readOnly}
Only the name is necessary. The visibility marker indicates whether the attribute is public (+), private (-), package (), protected (#). The name of the attribute (how the class refers to the attribute) roughly corresponds to the name of a eld in a programming language. type indicates a restriction on what kind of object may be placed in the attribute; roughly corresponds to type of a eld in a programming language. For the multiplicity, see discussion in the following slides. The default value is the value for a newly created object if the attribute isnt specied during creation. The {property-string} allows one to indicate additional properties for the attribute. E.g. {readOnly} to indicate that clients may not modify the property, or {frozen} to indicate that property is immutable. If it is missing, one can usually assume that the attribute is modiable.
Class diagrams
Responsibilities
One can also specify responsibilities

Model Responsibilities manage the state of the model View Controller
Responsibilities render the model on the screen manage movement and resize the view intercept user events
Responsibilities synchronize changes in the model and views
System Models III
27 / 118
Class diagrams
Relations
Relations
Objects of a class collaborate with objects of other classes. E.g. a house: Classes: walls, doors, windows, lights, ... Structural relationships: Walls adjoin other walls. Doors are built into walls, etc. Other relationships: Different kinds of windows. E.g. some can not be opened, others having single glass, others double, etc. UML supports modeling different relationships between objects or classes
Relationship Association Generalization Dependency Realization Usage Function Describes connection between instances of classes A relationship between a more general description and a more specic variety A relationship between two model elements Relationship between a specication and its implementation Situation where one element requires another for proper functioning Notation
Associations describe relationships between objects in a class. The others describe relationships between classes (or interfaces), instead of their instances.
Class diagrams
Relations
Associations
A link represents a connection between two objects:
Ability of an object to send a message to another object. Object A has an attribute whose value is B. Object A creates object B. Object A receives a message with object B as argument. Example: Fred borrows copy 17 of Book XYZ .
Associations denote relationships between classes:
Semantics: a relation like ERA models. Role: describes the roles played by objects in the association.
Makes relationships easier to read and understand. No semantic consequences.
Class diagrams
Relations
Associations can be annotated

Name, e.g. Works for or is capital of. The multiplicity of an association end denotes how many objects the source object can reference:
Exact number: 1, 2, etc. (1 is the default). Arbitrary number: (zero or more). Range: 1..3, 1..
Semantics: it constrains the relation.
System Models III
31 / 118
Class diagrams
Relations
Association: example
System Models III
32 / 118
Class diagrams
Relations
Qualied associations
System Models III
33 / 118
Class diagrams
Relations
Navigability: associations can be directed
Semantics: relation can be queried in the indicated direction. N.B.: One can omit details in the early modeling phases. The result is then ambiguous.
Class diagrams
Relations
Associations and properties

Much of the same information that one can show on an attribute appears on an association. For example, properties of an order as attributes and associations:
Order Date + dateReceived: Date [0..1] + isPrepaid: Boolean [1] + lineItems: OrderLine [*] {ordered} 0..1 * +dateReceived +isPrepaid Order 1 1 source target lineItems {ordered} Boolean
OrderLine
Which one to use? The choice is much more about emphasis than about any underlying meaning.
Use attributes for small things, such as dates or Booleans (in general, value types). Use associations for more signicant classes, such as customers and order.
Class diagrams
Relations
Multiplicity of a property
The multiplicity of a property is an indication of how many objects may ll the property, e.g.
1: an order must have exactly one customer. (This is the default multiplicity, but it is better to state it explicitly.) 0..1: a corporate customer may or may not have a single sales representative. : a customer need not place an order and there is no upper limit the number of orders a customer may place (zero or more orders).
System Models III
36 / 118
Class diagrams
Relations
Multiplicity of an attribute (cont.)
The following terms refer to the multiplicity of an attribute: Optional: implies a lower bound of 0. Mandatory: implies a lower bound of 1 or possibly more. Single-valued: implies an upper bound of 1. Multivalued: implies an upper bound of more than 1, usually . Advise: use a plural form for the name of a multivalued property. By default, the elements in a multivalued multiplicity form a set, so if you ask a customer for its Orders, they do not come back in any order.
If the ordering of the Orders has meaning, then add ordered at the end. To allow duplicates, add nonunique. To show the default explicitly: add unordered and unique. Collections(=multisets) are unordered and nonunique: add bag.
Class diagrams
Relations
Bidirectional associations
A bidirectional association is a pair of properties that are linked together as inverses:
owner Person 1 * Car
Car class has property owner:Person[1]. Person class has property cars:Car[*]. (I followed the convention to name the cars property in the plural form.) An inverse link implies that if one follows both properties, one should get back to a set that contains the starting point. Example: if I begin with a particular Fiat Uno, nd its owner, and then look at its owners cars, then that set should contain the Fiat Uno I started from.
One can label an association by using a verb phrase (in the style of data-modeling), and one can add a direction as well:
owns Person 1 * Car
System Models III
38 / 118
Class diagrams
Relations
Operations
Operations are the actions that a class knows to carry out. They correspond to the methods on a class (see [Fowler] for discussion). Operations that simply manipulate properties are often not shown as they can be inferred. The full syntax for operations is visibility name (parameter-list) : return-type {property-string} e.g. : + balanceOn (date: Date) : Money visibility is public (+), private (-), package (), protected (#). name is a string. parameter-list is the list of parameters for the operation. Parameters are notated in a similar way to attributes: direction name : type = default value name, type, and default value are the same as for attributes. direction indicates whether the parameter is input (in, which is the default), output (out), or both (inout). return-type is the type of the returned value, if there is one. {property-string} indicates property values that apply to the operation.
Class diagrams
Relations
Notes and comments
Notes are comments in a diagram and can be linked with a dashed line to the elements they are commenting
Car
includes SUVs and pickups but not motorbikes
System Models III
40 / 118
Class diagrams
Relations
Dependency
A dependency exists between two elements if changes to the denition of one element (the supplier or target) may cause changes to the other (the client or source). With classes, dependencies exist for various reasons:
one class sends a message to another, one class has another as part of its data, one class mentions another as a parameter to an operation.
If a class changes its interface, any message sent to that class may no longer be valid. UML allows one to depict dependencies between all sorts of elements: one uses dependencies to show how changes in one element might alter some other elements.
System Models III
41 / 118
Class diagrams
Relations
Dependency example
client Benefits Window dependency supplier Employee Benefits Data Gateway Employee Data Gateway
Example: dependencies one might nd in multilayered application: The Benefits Window class (a user interface, or presentation class) is dependent on the Employee class: a domain object that captures the essential behavior of the system (in this case, business rules). This means that if the Employee class changes its interface, the Benefits Window may have to change. Dependency is only in one direction, from presentation class to domain class. This way, we know that we can freely alter the Benefits Window without those changes having any effect on Employee or other domain objects. No direct dependency from Benefits Window to two Data Gateway classes. If these classes change, the Employee class may have to change, but if the change is only to the implementation of the Employee class, not its interface, the change stops there.
Class diagrams
Relations
On dependencies
UML has many varieties of dependency, each with particular semantics and keywords (see [Fowler]). Try, however, to minimize dependencies. Be selective and show dependencies only when they are directly relevant to the particular topic you want to communicate.
System Models III
43 / 118
Class diagrams
Relations
Constraint rules
Drawing a class diagram is essentially indicating constraints, e.g.
Order
dateReceived isPrepaid number : String price : Money dispatch() close() 1 Generalization {if Order.customer.creditRating is "poor", then Order.isPrepaid must be true} Constraint Class Multiplicity
Customer *
Association 1 name address creditRating():String
Corporate Customer
contactName creditRating creditLimit remind() billForMonth(Integer)
Personal Customer
creditCard# {creditRating()== "poor"}
Attributes Role Name
Operations
line items
* *
sales rep 0..1
Order Line
quantity : Integer price : Money isSatisfied : Boolean
Employee
Product
indicates that an Order can be placed only by a single Customer; each Line Item is thought of separately: one says 40 black pens, 30 blue pens, 50 red pens, not 120 things on their Order; Corporate Customers have credit limits but Personal Customers do not.
Class diagrams
Relations
Constraint rules
The basic constructs of association, attribute, and generalization do much to specify important constraints, but they cannot indicate every constraint. UML allows one to use anything to describe constraints; the only rule is that one puts them inside braces {}.
One can use natural language, a programming language, or the UMLs formal Object Constraint Language OCL, which is based on predicate calculus.
System Models III
45 / 118
Class diagrams
Relations
Aggregation and composition
System Models III
46 / 118
Class diagrams
Relations
Aggregation and composition (cont.)

Aggregation expresses a hierarchical part-of (has-a) relationship: Aggregation: whole-parts relation.
Diamond marks the whole. Typically no name. Implicitly is a part of.
Objects can simultaneously be part of several aggregates. Special form of association; in fact, difcult to distinguish from association. Use with care (for documentation purposes only)! Composition expresses a strong aggregation: Component cannot exist without aggregate. When the whole is deleted, so are the parts. Aggregation and composition can be documented like other associations: multiplicity, label, roles, ...
Class diagrams
Relations
Derived properties
Derived properties can be calculated based on other values. Notation: /property -- {constraint}
/ species that the property is derived. {constraint}, if present, species how to calculate the value of the property.
For example, a date range can have three properties: start date, end date, and the number of days in the period.
Date Range start: Date end: Date /length: Integer
{length = end start}
These values are linked, so we can think of the length as being derived from the other two values.
System Models III
48 / 118
Class diagrams
Relations
Derived associations
One can also have derived associations:
System Models III
49 / 118
Class diagrams
Relations
Interfaces and abstract classes

An abstract class is a class that cannot be directly instantiated.
Instead, one instantiates an instance of a subclass. Typically, an abstract class has one or more operations that are abstract.
An abstract operation has no implementation, but is a pure declaration so that clients can bind to the abstract class. One can also make properties abstract. An abstract class or operation can be indicated by italicizing the name or by using the label :{abstract}. An interface is a class that has no implementation, i.e. all its features are abstract. The keyword is interface.
System Models III
50 / 118
Class diagrams
Relations
Interfaces and abstract classes (cont.)

Classes have two kinds of relationships with interfaces: providing and requiring.
A class provides an interface if it is substitutable for the interface. A class requires an interface if it needs an instance of that interface in order to work (i.e. it depends on the interface).
<<interface>> Collection interface equals add abstract class
Order Line Items [*]
<<interface>> List get dependency (requires interface)
Abstract List equals get add implementation (provides interface) abstract method
Abstract List get add
overriding
System Models III
51 / 118
Class diagrams
Relations
Interfaces and abstract classes (cont.)

A more compact notation:
The fact that ArrayList implements List and Collection is shown by having ball icons (a.k.a. lollipops) out of it. (Lollipops are used also in other UML diagrams.) The fact that Order requires a List interface is shown by the socket icon. The connection is made by a dependency arrow.
Order Line Items [*]
List ArrayList
Collection
System Models III
52 / 118
Class diagrams
Relations
Reference objects and value objects

All objects have an identity, but identity is important for reference objects but not so important for value objects. Reference objects are such things as Customer. Identity is very important because one usually wants only one software object to designate a customer in the real world. Any reference to a Customer object will be through a reference or pointer. Hence, changes to a Customer are available to all users of the Customer. Equality of reference objects is equality of their identities. Value objects are such things as Date. There are often multiple value objects representing the same object in the real world, and these are all interchangeable copies. Example: one can have hundreds of objects that designate 01.01.08, and new dates are created and destroyed frequently. Equality of value objects is equality of the values they represent. Hence, one needs to write an equality test operator. Value objects should be immutable (frozen).
Class diagrams
Relations
Generalization and specialization
Relation between a general thing (superclass) and a specic thing (subclass). Sometimes called is-a. Semantically: an object of a subclass can be substituted for a superclass object.
Class diagrams
Relations
Multiple classication
Classication refers to the relationship between an object and its type: it is a type assignment. It is different from generalization, which is a subtype relation, but be careful as both are often spoken as is-a. Single classication: an object belongs to a single type, which may inherit from supertypes. Multiple classication: an object may be described by several types that are not necessarily connected by inheritance. Multiple classication is different from multiple inheritance:
Multiple inheritance: a type may have many supertypes but a single type must be dened for each object. Multiple classication: allows multiple types for an object without dening a specic type for the purpose.
Multiple classication is usually not possible in OO programming: each object must have one type even if this has many supertypes (multiple inheritance).
Class diagrams
Relations
Multiple classication (cont.)
UML 2 allows one to specify clearly which combinations are legal by

placing each generalization relationship in a generalization set, labeling the generalization arrowhead with the name of the generalization set (called discriminator in UML 1).
Single classication = single generalization set with no name. Generalization sets are disjoint: any instance of the supertype may be an instance only of the subtypes within that set.
Legal combinations of subtypes are: (Maschio, Paziente, Medico), (Maschio, Fisioterapista), (Femmina, Medico, Medico generico). Illegal combination: (Paziente, Medico, Infermiere), as it contains two types from the generalization set professione.
Class diagrams
Relations
Dynamic classication
Dynamic classication allows objects to change class within the subtyping structure (keyword dynamic), while static classication does not. Multiple dynamic classication is useful for conceptual modeling. For software perspectives, that is probably too much, and the vast majority of UML diagrams employ (and need) only single static classication.
System Models III
57 / 118
Class diagrams
Relations
Association classes
Association classes allow one to add attributes, operations, and other features to associations.
Student 1..* is taking 6 Module
is taking mark : int
An association class can be replaced with multiple associations

Student 1 1..* is taking 6 Module 1
Mark 6 mark : int 1..*
but note that association class adds an extra constraint: there can only be one instance of the association class between any two participating objects. Q: What is the semantics of these diagrams? Are the two equivalent?
Class diagrams
Relations
Object constraints
Associations correspond to relations, i.e., sets of tuples.
1..* is a copy of Copy 1..* 0..1 Book
is a copy of
0..1 Journal
One can introduce constraints to tighten the semantics (i.e., remove tuples).
1..* is a copy of Copy 1..* {xor} 0..1 Book
is a copy of
0..1 Journal
UML offers an extension, OCL, where constraints are given by logical formula. See appendix on OCL.
Class diagrams
Relations
Template (parameterized) classes

Several languages (e.g. C++) have a notion of a parameterized class (or template), which is useful for working with collections in a strongly typed language.
Example: dene behavior for sets in general by template class Set class Set <T> { void insert (T newElement); void remove (T anElement); ... and then use the general denition to make Set classes for more specic elements Set <Employee> employeeSet;
Set template class insert(T) remove(T) T template parameter
System Models III
60 / 118
Class diagrams
Relations
Template (parameterized) classes (cont.)

A use of a parameterized class, such as Set <Employee>, is called a derivation, which can be shown in 2 ways:
Derivation expression: <parameter-name::parameter-value>
Set<T::Employee>
Reinforce the link to the template and rename the bound element:
Set template class insert(T) remove(T) <<bind>> <T::Employee> EmployeeSet binding for parameter T template parameter
stereotype on refinement relationship
bound element
System Models III
61 / 118
Class diagrams
Relations
Template (parameterized) classes (cont.)

Reinforce the link to the template and rename the bound element:
Set template class insert(T) remove(T) <<bind>> <T::Employee> EmployeeSet binding for parameter T template parameter
stereotype on refinement relationship
bound element
Stereotype bind on renement relationship indicates that EmployeeSet will conform to interface of Set. One can think of EmployeeSet as a subtype of Set. N.B.: a derivation is not the same as subtyping: it is not allowed to add features to the bound element, which is completely specied by its template. One is adding only restricting type information, and to add features, one must create a subtype.
Class diagrams
Relations
Directed names
Describes the direction that a name should be read.
Person
Works for
Company
Independent of navigation (direction). Also no semantic consequences.
System Models III
63 / 118
Class diagrams
Relations
An example
School
1..*
has
1 1..*
0..1
Department
1..* 1..*
member attends
* * 1..*
assignedTo
1 1..*
Student
Course
teaches
* 1..*
chairperson Instructor
System Models III
64 / 118
Class diagrams
From Use Cases to objects
Analysis object model: motivation
System Models III
66 / 118
Class diagrams
Analysis object model: properties
System Models III
67 / 118
Class diagrams
Activities during object modeling
System Models III
68 / 118
Class diagrams
Approaches to class identication

Application domain approach: Ask application domain expert to identify relevant abstractions. Syntactic approach: Extract participating objects from ow of events in Use Cases. Use noun-verb analysis to identify components of the object model. Design patterns approach: Use reusable design patterns. Component-based approach: Identify existing solution classes.
System Models III
69 / 118
Class diagrams
Identifying classes
What constitutes a good class model?

The objects should satisfy the desired requirements. Classes should represent signicant classes of objects in the domain, in order to improve maintainability and reusability.
How does one create a good class model? One possibility is: Divine inspiration: When the result is good, everyone is happy! But classes have data and responsibilities. Other possibilities are: Data driven design: Identify all system data and divide it into classes. Afterwards consider operations. Responsibility driven design: Start with the operations or even the responsibilities (as in the last example).
System Models III
70 / 118
Class diagrams
Procedure I: classes as nouns
Two step procedure for identifying classes:

1
Identify possible classes. These are the nouns and noun-phrases used in the requirements analysis. Use the singular. Consolidate the results. Delete those whose name is
redundant (one of many equivalent names), unclear (alternative: further clarify), an event or an operation (without state, behavior, and identity), a simple attribute, outside of the system scope, e.g. a library system probably doesnt require a library class. Dont forget, the objects are the system!
Experience, imagination, and patience are helpful.
System Models III
72 / 118
Class diagrams
Noun-verb analysis (Abbotts textual analysis)
Do a textual analysis of problem statement. Take the ow of events and nd participating objects in use cases and scenarios:
Nouns are good candidates for classes. Verbs are good candidates for operations.
Works well for short, structured texts.

Problem statement. Flow of events in Use Cases.
System Models III
73 / 118
Class diagrams
Textual analysis example: problem statement
The library contains books and journals. It may have several copies of a given book. Some of the books are for short-term loans only. All other books can be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of the staff may borrow up to 12 items at one time. Only members of the staff may borrow journals.
System Models III
74 / 118
Class diagrams
Textual analysis example: nouns
System Models III
75 / 118
Class diagrams
Textual analysis example: selecting classes
Library: inside or outside the system? Book, journal, copy: candidates for classes. Loan: property or event. Library member: candidate for a class. Week: unit of measurement. Items: used to refer to books and journals. Time: event. Staff members: candidate for a class.
System Models III
76 / 118
Class diagrams
Textual analysis example: class diagram
System Models III
77 / 118
Class diagrams
Textual analysis example: verbs
System Models III
78 / 118
Class diagrams
Textual analysis example: class diagram (cont.)
System Models III
79 / 118
Class diagrams
Textual analysis example: class diagram (cont.)
System Models III
80 / 118
Class diagrams
Textual analysis example: remainder

The library contains books and journals. It may have several copies of a given book. Some of the books are for short-term loans only. All other books can be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of the staff may borrow up to 12 items at one time. Only members of the staff may borrow journals. Attribute in borrowable. Precondition for borrow.
System Models III
81 / 118
Class diagrams
Mapping speech to object models
System Models III
82 / 118
Class diagrams
Problems of noun-verb analysis
Natural language is imprecise.

Identify and standardize terms. Rephrase and clarify requirements specication.
Many more nouns than relevant classes.

Eliminate synonyms; use same word for the same thing. Many nouns correspond to attributes.
System Models III
83 / 118
Class diagrams
Procedure II: CRC Cards

Alternative approach suggested by Beck & Cunningham in 1989 (pre-UML). For each class, one notes on a card: Class: Name. Responsibilities: of objects of the class. Collaborators: helpers that aid in fullling the responsibilities. If there are too many responsibilities or collaborators, create new classes! Distribute the card to the developing team and choose a Use Case scenario.
Play the scenario through, switching, as necessary, between the collaborators. In doing so, discover missing responsibilities or collaborators.
Afterwards, add attributes and methods.

Class diagrams
Brainstorming with CRC Cards

L IBRARY M EMBER Responsibilities Maintain data about copies currently borrowed Meet requests to borrow and return copies C OPY Responsibilities Maintain data about a particular book copy Inform corresponding B OOK when borrowed and returned B OOK Responsibilities Maintain data about one book Know whether there are borrowable copies
Luca Vigan (Universit di Verona) System Models III
Collaborators C OPY
Collaborators
B OOK
Collaborators
86 / 118
Class diagrams
Different kinds of object
System Models III
88 / 118
Class diagrams
Identifying entity objects
For each Use Case, participating objects are.

Identied (e.g. by noun-verb analysis). Named by application domain terms. Described and collated in a glossary.
Results in the initial analysis model.
System Models III
89 / 118
Class diagrams
Heuristics for identifying entity objects

Terms the developers or users must clarify to understand the Use Case (e.g. account). Recurring nouns in the Use Case (e.g. card). Real-world entities that the system must track (e.g. cash dispenser). Real-world processes that the system must track. Data sources or sinks (e.g. host).
Account
Currency
System Models III
90 / 118
Class diagrams
Cross checks
Use Cases and initial analysis models can be improved by cross-checking:

Which Use Case creates this object? Which actors can access this information? Which Use Cases modify and destroy this object? Which actors can initiate these Use Cases? Is this object needed? (Is there at least one Use Case that depends on this information?)
System Models III
91 / 118
Class diagrams
Identifying boundary objects
Boundary objects collect information from actor. Boundary objects translate information into format for entity and control objects. Boundary objects do not model details and visual aspects (e.g. menu item, scrollbar). Each actor interacts with at least one boundary object.
System Models III
92 / 118
Class diagrams
Heuristics for identifying boundary objects
User interface controls to initiate the Use Case (e.g. bank card). Forms to enter data (e.g. option screen). Messages the system uses to respond (e.g. termination message)
Terminal
Display
System Models III
93 / 118
Class diagrams
Identifying control objects
Control objects coordinate boundary and entity objects. Control objects usually do not have a concrete counterpart in the real world. Control objects are typically created at beginning of Use Case and exist to its end. Control objects collect information from boundary objects and dispatch it to entity objects. Examples:
Sequencing of forms, undo and history queues. Dispatching information in distributed systems.
System Models III
94 / 118
Class diagrams
Heuristics for identifying control objects
Identify one control object per Use Case. Identify one control object per actor in the Use Case. Life span of a control object should cover the extent of a Use Case or user session.
Withdrawal
System Models III
95 / 118
Class diagrams
Stereotypes and conventions
System Models III
96 / 118
Class diagrams
UML packages
System Models III
97 / 118
Class diagrams
Avoid ravioli models
System Models III
98 / 118
Class diagrams
Put taxonomy on a separate diagram
System Models III
99 / 118
Class diagrams
Summary: ways to nd objects
Syntactical investigation with Abbotts technique:

In the problem statement. In the ow of events of Use Cases.
Use of various knowledge sources: Application knowledge: Interviews of users and experts to determine the abstractions of the application domain. Design knowledge: Reusable abstractions in the solution domain. General world knowledge: Use your empirical knowledge and intuition.
System Models III
100 / 118
Conclusions
Outline
1
2 3 4 5
System Models III
101 / 118
Conclusions
Key points
Class diagrams support the modeling static, structural relationships. Central concept of OO-modeling and design! UML offers even more (parameterization, visibility, qualiers, etc.) Case-studies in more detail later.
System Models III
102 / 118
References
Outline
1
2 3 4 5
System Models III
103 / 118
References
References
Martin Fowler UML distilled (3rd ed.). Addison Wesley Sinan Si Alhir UML in a nutshell. OReilly Jos Warmer and Anneke Kleppe The Object Constraint Language 2nd Edition
Addison-Wesley, Pearson Education (2003).

http://www.klasse.nl/ocl Object Management Group UML OCL2 Specication
FTF ptc/2005-06-06 (June 2005).

http://www.omg.org/cgi-bin/doc?ptc/2005-06-06 Anneke Kleppe, Jos Warmer, and Wim Bast MDA Explained; The Model Driven Architecture: Practice and Promise
Addison-Wesley, Pearson Education (2003). System Models III
104 / 118
Homework
Outline
1
2 3 4 5
System Models III
105 / 118
Homework
Example solution of the last homework

Following the general product sketch of the previous analysis phase, in particular section II and section III, we get the following high-level Use Case diagram (more rened diagrams can of course be given):
Class Scheduling System
edit rooms browse personal schedule edit event offers
instructors
browse roomschedule students scheduling manager generate/browse class schedules
generate/browse personal and room schedules others
System Models III
106 / 118
Homework
Homework
We continue with the semi-formal analysis of the requirements of our Class Scheduling System software-project.
1 2
Model the requirements of CSS using CRC-cards. Give a coarse data-model using class diagrams.
System Models III
107 / 118
Appendix: The Object Constraint Language OCL
Outline
1
2 3 4 5
System Models III
108 / 118
What is OCL?
The Object Constraint Language OCL is a modeling language with which one can build software models. It is dened as a standard add-on to the UML, which, as we saw, is the standard of the Object Management Group OMG, for object-oriented analysis and design. History of OCL: 1997: v. 1, included by the OMG in UML 1.1. 2003: v. 2, proposal, in UML 2.0 [Warmer and Kleppe, 2003]. 2005: v. 2, specication, in UML 2.0 [OMG, 2005]. Every expression written in OCL relies on the types (i.e. the classes, interfaces, and so on) that are dened in the UML.
System Models III
109 / 118
OCL expressions
OCL expressions allow one to add information that often cannot be expressed in a diagram. Constraint: restriction on one or more values of (part of) an object-oriented model or system. Other information: expressions also allow for dening queries, referencing values, stating conditions and business rules in a model, ... OCL expressions can be written in a clear and unambiguous manner.
System Models III
110 / 118
Why combine UML and OCL? An example

An example of the limited expressivity of UML diagrams:
Diagram says that number of passengers is unlimited (0..). For a more realistic model: restrict (constrain) the model! With OCL: context Volo inv: passeggeri->size() <= aereo.posti
System Models III
111 / 118
Why combine UML and OCL? Another example

Another example of the limited expressivity of UML diagrams:
Several obvious restrictions are not specied in the diagram. . . For precision, we should specify the following constraints (and not just in natural language!):
Why combine UML and OCL? Another example (cont.)

1 Si possono ipotecare solo case di cui si proprietari.
context Mutuo inv: garanzia.proprietario = contraente

2 Data di inizio di un mutuo deve essere anteriore alla data della sua ne.
context Mutuo inv: dataInizio < dataFine

3 Il codice scale di ciascuna persona deve essere unico.
context Persona inv: Persona::allInstances()->isUnique(codiceFiscale)

4 Un mutuo concesso solo a chi dispone di un reddito annuo sufciente.
context Persona::ipoteca(somma:Denaro, garanzia:Casa) pre: self.mutui.rataMensile->sum() * 12 <= self.redditoAnnuo * 0.30

5 Un mutuo viene concesso solo in presenza di una garanzia sufciente.
context Persona::ipoteca(somma:Denaro, garanzia:Casa) pre: garanzia.valore >= garanzia.mutui.capitale->sum()

Why combine UML and OCL? Summing up

UML+OCL more precise and complete models.
Even a simple three-class model needs much additional information to make it complete, consistent, and unambiguous. The models provided by UML diagrams alone (i.e. without OCL expressions) are severely under-specied. Without the UML diagrams, the OCL expressions would refer to non-existing model elements (as there is no way in OCL to specify classes and associations).
Expressions written in a precise, mathematically-based language like OCL offer a number of benets over the use of diagrams to specify a system.
These expressions cannot be interpreted differently by different people (e.g. an analyst and a programmer). They are unambiguous and make the model more precise and more detailed. They can be checked by automated tools to ensure that they are correct and consistent with other elements of the model. Hence, code generation becomes much more powerful.
OCL: both query and constraint language
OCL can be used to write not only constraints, but any expression on the elements in a diagram.
Every OCL expression indicates a value or object within the system. Example: the expression 1 + 3 is a valid OCL expression of the type Integer, which represents the integer value 4. When the value of an expression is of Boolean type, it may be used as a constraint.
System Models III
115 / 118
Characteristics of OCL (cont.)

Expressions can be used anywhere in a model to indicate a value.
A value can be:
a simple value (e.g. an integer), a reference to an object, a collection of values, a collection of references to an object.
An expression
can represent, e.g., a Boolean value used as a condition in a statechart or a message in an interaction diagram, can be used to refer to a specic object in an interaction or object diagram. For example, the following expression denes the body of the operation postiLiberi() of the class Volo: context Volo::postiLiberi() : Integer body: aereo.posti - passeggeri->size()
OCL is a constraint and query language at the same time (it has the same capabilities as SQL).
OCL: mathematical foundation
OCL is based on set theory and predicate logic. It has a formal mathematical semantics. Actually, different semantics can be given. The notation, however, does not use mathematical symbols. Hence, OCL has the rigor and precision of mathematics, but the ease of use of natural language. OCL even allows users to dene their own syntax (as long as this syntax can be mapped to the language structures dened in the standard).
System Models III
117 / 118
OCL: strongly typed and declarative language

OCL is a strongly typed language:
Hence, OCL expressions can be checked during modeling, before execution of the system, and errors in the model can be removed at an early stage.
OCL is a declarative language:

An expression simply states what should be done but not how. To ensure this, OCL expressions have no side effects: evaluating an OCL expression does not change the states of the system.
For example, postiLiberi() clearly species what the operation should calculate, but how this should be done will depend on the implementation strategy of the whole system.
context Volo::postiLiberi() : Integer body: aereo.posti - passeggeri->size()
System Models III
118 / 118

System Models III: Luca Viganò

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

System Models III: Luca Viganò

Caricato da

Copyright:

Formati disponibili

System Models III

Ingegneria del SW, 06.04.11

Luca Vigan (Universit di Verona)