Topics

1. Topics • The Unified Modeling Language • UML Extension Mechanisms • Advanced Modeling with OCL • Hands-on: Writing the Constraint using OCL • UML Modeling Techniques for Component System • Business Concept Model • Use Case Model • Business Type Model • Interface Specification • Component Specification • Component Architecture • Module Summary • Hands-on: UMLGame

2. What is UML? • Integrate diagrams of many methodologies: • Booch, OMT, OOSE, Fusion, Coad/Yourdon • Added to the list of OMG adopted technologies in 1997 as UML 1.1 • The UML is a language of software development • Specifying • Visualizing • Constructing • Documenting the artifacts of software system. • Object Modeling, Component Packaging • be used to describe just the Component Specification

3. What Does UML Do? + • Use case diagram • Describes a system's functional requirements in terms of use cases. • Class diagram • Shows a collection of declarative static model elements. • Behavior diagram • Statechart Diagram • Shows behavior that specifies the sequences of states that an object or an interaction goes through during its life in response to events, together with its responses and actions. • Activity Diagram • Shows behavior with control structure. • Interaction Diagram • Sequence Diagram • Shows object interactions arranged in time sequence. • Collaboration Diagram • Shows interactions organized around the structure of a model. • Implementation diagram • Component Diagram • Shows the organizations and dependencies among components. • Deployment Diagram • Shows the configuration of run-time processing models and the components, processes, and objects that live on them.

4. Why We Need to Extend UML? • UML was originally designed for OOA/D and based on the assumption of an OO implementation. • Our focus is on the external aspects of components and not internals, irrespective of whether they are coded using an OO language. • Component emphasize the need for clear and precise interface definition. • Although our views on interface specification fit within UML, they cause us to use it in new ways. • We are interested in techniques rather then diagrams. • The same UML diagram can be used for a variety of purposes (to support Component concepts). • Business modeling • Data modeling • Object modeling • Component modeling • UML is designed to be extended.

5. <<interface type>> ICustomerMgt <<interface type>> UML Extension Mechanism • Extensibility Mechanisms • Allow Modelers to refine the semantics of UML for a specific domain. • Extensions cannot violate the standard UML semantics • Enforces a consistent core of concepts and semantics for every variation. • Prevents meta-model explosion (Using UML to model everything and anything). • Extensibility Method • Refinements are specified at the Model (M1) level but apply to the Meta-Model level (M2). CustomerOrder item quantity Customer id M1 Class Association M2

6. {author = “NKCho”} {status = draft} <<entity>> Account balance getBalance( ) {or} Person Corporation Basic Extension Mechanisms and Profiles + • Stereotypes • used to define specialized model elements based on a core UML model element. • Constraint • used to represent semantic information attached to a model element. • Tagged Value • used to attach new properties into model element. • UML Profile • A package of related extensibility elements that capture domain-specific variations and usage patterns. • UML for CORBA, UML for RealTime, etc.

7. Extending UML with Stereotypes • optional • often omitted

8. Precision, Accuracy, and Completeness • Q: “How much did you pay for these apples?” • We need to model more precise, accurate, and complete. A: “Big money” Imprecise A: “Over $10” Precise, but not Accurate A: “$11” Precise and Accurate, but not Complete A: “$11 per one” Precise, Accurate, and also Complete

9. What is Object Constraint Language(OCL)? + • Constraint • is a restriction on one or more values of (part of) an object-oriented model or system. • UML defines three standard stereotypes for constraints: • Class invariant • a constraint that must always be met by all instances of the class. • Pre-condition of an operation • a constraint that must always be true BEFORE the execution of the operation. • Post-condition of an operation • a constraint that must always be true AFTER the execution of the operation. • OCL is • a textual language to describe constraints. • the constraint language used in UML models. • formal, but easy to use.

10. What Does OCL Do? • OCL invariants allow you to • Model more precisely. • Remain implementation independent. • OCL pre- and post-conditions allow you to • Specify contracts (design by contract). • Specify interfaces of components more precisely.

11. Basic OCL Keywords and Syntax • Basic keywords • context – introduce context for the expression. • self – a reserved word that indicate constraint context. similar to “this” in C++. • inv – denote the <<invariant>> stereotype. • pre – denote the <<precondition>> stereotype. • post – denote the <<postcondition>> stereotype. • package & endpackage - specify explicitly in which package constraints belong. • if, then, else, endif, not, let, or, and, xor, implies, def, in • Syntax: package Package::SubPackage context X inv: -- some invariant context X::operationName(..) pre: -- some pre-condition post: -- some post-condition endpackage

12. Person isMarried: Boolean isUnemployed: Boolena birthDate: Date age: Integer firstName: String lastName: String sex: Sex income(Date): Integer manager 0..* Company name:String numberOfEmployee: Integer stockPrice(): Real managedCompanies employee employer 0..* 0..* Job title: String startDate: Date salary: Integer Example: Specifying an Invariant • Constraint: • “In the context of the Company type, the number of employees must always exceed 50.” • OCL expression: package UML_OCL context Company inv: self.numberOfEmployees > 50 endpackage

13. Elements of OCL Expression • Predefined OCL Types • Basic Types • Boolean, Integer, Real, String • Collection Types • Classifiers from the UML model, their Features and Associations. • Example: Basic Type • context Person inv: • self.lastName = ‘CHO’ • Example: Model Class and Attribute • context Person inv: • self.age > 0 • Example: Query Operation • context Person::income(d: Date): Integer • pre: -- none • post: result = age * 1000 • context Company inv: • self.stockPrice() > 0 • Example: Association and Navigation • context Company • inv: self.manager.isUnemployed = false • inv: self.employee->notEmpty()

14. Job title: String startDate: Date salary: Integer Person isMarried: Boolean isUnemployed: Boolena birthDate: Date age: Integer firstName: String lastName: String sex: Sex income(Date): Integer manager 0..* Company name:String numberOfEmployee: Integer stockPrice(): Real managedCompanies employee employer 0..* 0..* Collection Type • Most navigations return collections rather than single elements. context Company inv: self.employee • Collection type • Collection type is predefined in OCL to manipulate collections. • Collection is an abstract type, with the concrete types as its subtypes: • Set – is the mathematical set. It does not contain duplicate elements. • Bag – is like a Set, which may contain duplicates. • Sequence – is like a Bag in which the elements are ordered. employee 0..*

15. Collection Operations • OCL predefines many operations on the collection types. • Syntax: collection->operation(v : Type | boolean-expression-with-v) • Collection operations • select – results in a Collection that contains all elements for which boolean-expression is true. • forAll – results in a Boolean that is true if the boolean-expression is true for all elements of collection. • exist – results in a Boolean that is ture if the boolean-expression is true for at least one element of collection. • isEmpty – results in a Boolean that is true if collection has no elements. • notEmpty – results in a Boolean that is true if collection has at least one element. • size – results in a Integer that is the number of elements in collection.

16. :Person age = 32 lastName = ‘CHO’ :Person age = 29 lastName = ‘KIM’ :Person age = 34 lastName = ‘LEE’ :Person age = 34 lastName = ‘MIN’ legend: — manage — employee :Company name = ‘Mananim’ :Company name = ‘SolutionLink’ Example: Collection Operations context Company inv: self.employee->select(p : Person | p.age < 20)->isEmpty() context Company inv: self.employee->forAll(p : Person | p.age >= 20 and p.age < 60) context Company inv: self.employee->exists( p : Person | p.lastName = 'CHO' )

17. More OCL Concepts • Local variables • The let expression allows one to define an attribute or operation which can be used in the constraint. • Syntax: Let var : Type = <expression1> in <expression2> • Result in post-condition • result indicates the return value from the operation. In this case, “result” is of type Integer. • Example context Person::income (d: Date) : Integer pre: -- none post: Let income : Integer = self.job.salary->sum() in result = self.income

18. Modeling Tips • Keep constraints simple. • Always combine natural language with OCL. • Use a tool to check your OCL. +

19. IStack stack[]: Stack size: Integer MAX = 5 push(item: Data) pop(): Data isEmpty(): Boolean isFull(): Boolean • context IStack inv: • self.size >= 0 • self.size < MAX • initial: self.size = 0 ? context IStack::push(item: Data) pre: self.size < MAX post: self.size = self.size@pre + 1 self.stack[size] = item context IStack::pop(): Data pre: self.size > 0 post: result = self.stack[size] self.size = self.size@pre - 1 context IStack::isEmpty(): Boolean pre: -- none post: result = ( self.size = 0 ) context IStack::isFull(): Boolean pre: -- none post: result = ( self.size = MAX ) Hands-on: Writing the Constraint using OCL • Stack is a storage structure. All storage locations are initially empty. An item of data is added to top of the stack by a “push” instruction, which pushes any previously stored items further down in the stack. Only the topmost item on the stack is accessible at any moment, and it is fetched and removed from the stack by a “pop” instruction. • Consider the above constraints, write the pre/post-condition pairs for following operations.

20. Sample Solution context IStack::push(item: Data) pre: self.size < MAX post: self.size = self.size@pre + 1 self.stack[size] = item context IStack::pop(): Data pre: self.size > 0 post: result = self.stack[size] self.size = self.size@pre - 1 context IStack::isEmpty(): Boolean pre: -- none post: result = ( self.size = 0 ) context IStack::isFull(): Boolean pre: -- none post: result = ( self.size = MAX )

21. UML Modeling Techniques • Term • In UML, Model is an abstraction of physical system with a certain purpose. • In this Course, Model is a self-contained set of model element. • General Techniques • Use case Diagram • to capture the business concepts in the domain being studied. • to understand the interaction between the users and the system. • Class Diagram • to capture the structural or static aspects of the specification model. • Interaction Diagram • to capture the behavioral or dynamic aspects of the specification model. • Package Diagram • to group the related model elements. • Activity Diagram (for special purpose) • to describe business processes. • to describe the algorithms of operations. • Not use • component and deployment diagram • statechart diagram

22. Use Case Diagram Business Concept Model Class Diagram Requirements Use Case Model Business Concept Model Use Case Model Business Type Model Specification Interface Specification Model Class Diagram Business Type Model Interface Responsibility Model Interface Specifications Component Specification Model Component Specifications Component Architecture Component Architecture Model Component Interaction Model Interactions Collaboration Diagram Package Diagram Diagrams for Component Modeling

23. Business Concept Model • Term • Business concept is not software, but the information that exists in the problem domain. • Purpose • Capture business concepts and identify its relationships. • Representation • Class diagram with <<concept>> stereotype. • Modeling techniques • Capture conceptual classes and their associations. • Association roles may or may not have their multiplicities specified. • May contain attributes, if they are significant. • Operation would not be used. • Normalization, generalization and dependency relationship would typically not used. • Emphasize capturing domain knowledge.

24. Customer Order Outlet Product Price Account number 1 Example: Business Concept Diagram

25. Use Case Model • Terms • Use case is a projection of the requirements of a system, expressed in terms of the interactions that must occur across the system boundary. • Actor is a coherent set of roles that interacts with system. • Purpose • Describe the desired user-system interactions that occur at the system boundary. • Representation • Use case diagram. • Modeling Techniques • One actor is always identified as the actor who initiates the use case. • Use case shouldn’t be concerned with the communication mechanism, only with the business meaning of the stimuli and responses. • Use case is smaller than a business process, but larger than a single operation on a single component. • Use case is to meet the immediate goal of actor.

26. Reservation system Cancel a reservation ReservationMaker Make a reservation Update a reservation Guest Take up a reservation Process no shows BillingSystem Add, amend, remove hotel, room, customer, ... ReservationAdministrator Example: Use Case Diagram

27. Use Case Descriptions • UML does not specify the way in which use case content is described. • Content of Use Case Description (from Alistair Cockburn) + • An identifying name and/or number • The name of the initiating actor • A short description of the goal of the use case • A single numbered sequence of steps that describe the main success scenario • Specifying Techniques • Each step takes the form “A does X”. • The first step must indicate the stimulus that initiates the use case. • The main success scenario describes what happens in the most common case and nothing goes wrong. • Each step acts as a UML use case extension point. • Use case steps are always written in natural language.

28. Steps or Extension Points ReservationMaker Make a reservation <<extend>> Room Not Available Example: Textual Description of a Use Case Name: Make a Reservation Initiator: Reservation Maker Goal: Reserve a room at a hotel Main success scenario: • Reservation Maker asks to make a reservation. • Reservation Maker selects hotel, dates and room type. • System provides availability and price. • Reservation Maker agrees to proceed. • Reservation Maker provides name and post/zipcode. • Reservation Maker provides contact email address. • System makes reservation and gives it a tag. • System reveals tag to Reservation Maker. • System creates and sends confirmation by email. Extensions: • Room Not Available • System offers alternative dates and room types. • Reservation Maker selects from alternatives. • Customer already on file • Resume 7.

29. Inclusions, Extensions, and Variations • Inclusion • Indicates one use case include another use case. • Extension • A mechanism for semiformal specification of alternatives or additions to the main success scenario. • Content of extension • the step number in the main success scenario at which the extension applies. • a condition that must be tested before that step. • a numbered sequence of steps that contributes the extension. • Last step in an extension can take one of the following forms: • Fail –use case is terminated with the goal unsatisfied. • Stop –use case is terminated with the goal satisfied. • Resume N –next step to be performed in the main success scenario. • Variation • Indicates variations of the flow of a use case that we don’t want to specify them as extensions.

30. Business Type Model • Term • Business Type represent the system’s understanding of the business concept, which is typically scoped down and more precisely defined. • Purpose • Represent precisely the business information that is relevant to the scope of the envisaged system. • Representation • Class diagram with built-in stereotype <<type>>. • Modeling techniques • Complete association with multiplicity, optionality, and association roles. • Recording attributes that you know about. • scope back to data that the business needs to keep track of within the scope of this project. • Remove redundancy. • Use generalization concept.

31. <<type>> Account <<type>> Customer <<data type>> Address * number: String startDate: Date 1 name: String address: Address billing: String delivery: String 1 * <<type>> Product <<type>> Order <<type>> OrderLine 1 * 1..* 1 price: Currency code: String description: String number: Integer number: Integer Example: Business Type Diagram

32. Other Concepts in the Business Type Model • (Business) Types • Intended to represent precisely the information about the business with which the system will need to be concerned. • But it is not database design. • Can’t have operations because they describe only information, not software. • Give <<type>> stereotype. • Structured Data Types • A descriptor of a set of values that lack identity. • May not have associations, or operations. • Give <<data type>> stereotype. • Interface Type • An interface at the specification level. • UML interface is a realization of an interface type. • Give <<interface type>> stereotype.

33. <<interface type>> IOrderMgt orderNo: Integer addItem(p: IProductMgt, quantity: Integer) orderNo(): Integer context IOrderMgt inv: self.orderNo > 0 context IOrderMgt::orderNo(): Integer pre: -- none post: result = self.orderNo Adding Invariants into Business Type Model • A constraint that applies to all instances of a type. • Write invariants using the OCL. • Correspond to business rules. • Example:

34. Interface Specification • Term • An interface together with all the other specification paraphernalia needed to define precisely what a component that offers that interface must do, and what a client of that interface can expect. • Content of Interface Specification • The interface type itself. • Its Information Model. • Its Operation Specifications. • Any additional Invariants on the information model. • Interface Specification Package • Group all specification information into a single package. • each interface specification has its own package. • A package may import specification information from other packages.

35. Shared Data Types <<info type>> Customer <<data type>> CustDetails <<data type>> Address <<import>> ICustomerMgt name: String address: Address name: String address[0..1]: Address billing: String delivery: String <<interface type>> ICustomerMgr addCustomer(c: CustDetails) deleteCustomer(name: String) * Example: Interface Specification Diagram

36. Information Model and Operation Specification • Information Model • Whereas in business type model we had a single integrated type model, interface information model define a number of type models, one for each interface. • Consists of an interface and an exclusive set of information type. • Represented by interface specification diagram with <<info type>> stereotype. • Operation Specification • Operation name • Intent of the operation in free text • Signature, which define its parameters • Pre/postcondition pair • <<precondition>>: Boolean expression that is evaluated before the operation executes. • <<postcondition>>: Boolean expression that is evaluated after the operation finishes. • Transaction behavior • operation starts its own transaction. • <<transaction>> • or runs in an existing transaction.

37. Component Specification • Term • A component specification describe the behavior of a component. It may be given to an implementer to tell them what to implement, or may be given to a customer, to tell them what has been implemented. • Purpose • Represent the functional specification of the component plus certain aspects of the component’s delivery information. • Representation • Class diagram with <<comp spec>> stereotype, <<offers>> relationship, and <<usage>> dependency. • Modeling techniques • Component specification defines the set of interfaces it must use as well as the set of interfaces it offers. • Focuses on a single component specification and details its individual dependencies. • Also defines any constraints that it requires between interfaces, and any constraints on the implementation of its operations.

38. CustomerMgr <<interface>> ICustomerMgt <<realize>> <<realize>> <<comp spec>> CustomerMgr <<interface type>> ICustomerMgt <<offers>> <<usage>> <<interface type>> IAddressMgt Example: Component Specification Diagram

39. Component Object Interaction • Term • Interaction is a specification of how stimuli are sent between instances to perform a specific task. • Purpose • Show how component object uses the interfaces of other component objects. • Representation • Collaboration diagram (or Sequence diagram.) • Modeling techniques • Follow the object naming rule, ObjectName/RoleName:ClassifierName • Only component object can send messages. • Only show direct interactions between objects of the type being specified and objects supporting the interfaces it uses. • Every interaction diagram should show the stimulus that causes the interaction.

40. /ICustomerMgt:CustomerMgr 1: getAddress(cid, ad) /Client:Client 1.1: getAddress(aid, ad) /IAddressMgt /ICustomerMgt:CustomerMgr /IAddressMgt /Client:Client 1: getAddress(cid, ad) 1.1: getAddress(aid, ad) Example: Component Interaction Diagrams

41. Component Architecture • Term • A set of application-level software components, their structural relationships, and their behavioral dependencies. • Purpose • Show the organizations and dependencies among components. • Representation • Class diagram with <<comp spec>> stereotype. • Modeling techniques • Integrate individual components into a single component architecture. • Can draw component architecture diagrams without the interfaces to give a coarser-grain view.

42. <<comp spec>> CustomerMgr ICustomerMgt <<comp spec>> AddressMgr IAddressMgt <<comp spec>> CustomerMgr <<comp spec>> AddressMgr Example: Component Architecture Diagram

43. Module Summary • We can use UML to represent the component specifications and model artifacts. • We need to extend the UML. • We can make our model more precisely by using OCL. • UML Modeling Techniques

44. Hands-on: UML Game – Use case • Microwave Sharp 1000 • Think about the functionalities of Microwave Sharp 1000. • Identify actors and use cases of the Microwave Sharp 1000: • Define the actor. • Think about the functionalities you need to support those two high level functionalities. • Define the use cases and the kind of relationships. • Model them in use case diagram. start timer door

45. Sample Solution – Use case Microwave Sharp 1000 <<extend>> Open door Stop cooking Close door Set timer Cook Heating <<include>> Start cooking Timer off <<include>>

46. Hands-on: UML Game – Object and Class • Conference Management System • To create a conference you may need a conference subject and a conference start and end date. • A conference consists of several conference events. • A conference event must have a speaker. • A conference event may not start before the conference has started. • You may ask a conference how many persons may attend. • A person registers to a conference by using a specific registration types(attendee, employee, guest, VIP, ...) • Identify objects and classes: • Find possible classes based on the description above. • Find and define attributes for those classes. • Identify relationships between those classes. • Think about the behavior of those objects. • Define methods for the classes you found. • Model them in class diagram.

47. Conference subject startDate endDate cost start() close() Registration Attendee entryDate paymentDate registrationType 1 * * Participant 1 name companyName address * PaymentInformation Event method title startDate duration room seat areSeatAvailable() * presenter Speaker Event.startDate >= Conference.startDate * registrationType = {attendee, employee,guest, VIP} Sample Solution – Object and Class