Rigoros and Adaptive... Service-Driven Applications1 Development of Rigorous Adaptive Information...

Rigoros and Adaptive ... Service-Driven Applications 1

Development of Rigorous Adaptive Information

Systems

Dr. Nasreddine AoumeurFIN, ITI, DB group

[email protected]

Course Site: wwwiti.cs.uni-magdeburg.de/~aoumeur wwwiti.cs.uni-magdeburg.de/iti_db/lehre/oois/inde


Service-Driven Applications Rigorous Development OO Concepts and UML Method

Dr. Nasreddine AoumeurFIN, ITI, DB group

[email protected]

wwwiti.cs.uni-magdeburg.de/~aoumeur wwwiti.cs.uni-magdeburg.de/iti_db/lehre/soa


Information Systems: Working Information Systems: Working definitiondefinition

– reactive systems (i.e. in continuous interaction with their environment), with

– large amount of immutable and non-immutable data (i.e. fixed and changing) and, with

– processes and activities for exhibiting behaviors on these (state-less and –full) data.


Different generations of CMs : “Entity first”

State-less and -ful DATA

Processes and Rules

IS Conceptual ModelEntity-Relationship[1973..] - Intuitive / Simple - Revolutionary for IS - UoD : Entities+Relations - Mathematically sound - Rich abstraction mechnanisms - Different variants (NIAM / SADT / MERISE / ..)

Process-centric Formalisms - CCS, CSP, DFD, Petri Nets, .. - Synchronous / asynchronous - Mathematically sound - Executable / operational


CMs Generation shift: “Entity To Object”

Processes, Operations and Rules

From E/R to “Object-Object

Entity Name

Attribute1 : Type1

Attribute2 : Type2....Attributei : Typei

Property1

.....

n-m

i-j AssocPART

IS-A

m Entit(ies)

n Entit(ies)

data

data

operation

sop

erations


First generation of CMs : “Entity to Object”E/R Conceptual Model

Customer

Name : StringBirth-Date : DateAddress : AddressIncome : Money

Open-Date

Bank

1-20-N Own

(Running) Account

Number : NatBalance : MoneyLimit : MoneyHistory : List[Date,Money]

IS-A

Saving Account

Number : NatInterest : PercentBalance

Processes and RulesAccount USE : First open --- then deposit – then (withdraw-deposit)* - then Close-or-be-closed


CMs generation shift : “From Entity to object”From E/R to Object Model : Banking Example

Customer

Name : StringBirth-Date : DateAddress : AddressIncome : Money Open-Date

Bank

1-20-N Own

(Running) Account


Processes,operations and RulesAccount USE: First open - then deposit –> then (withdraw-deposit)* --> then Close-or-be-closed

+op

en- closed

eposit

with

draw

+open (date, bank)-close(date)-Debit(Amount)-Credit(Amount)

Own(account) : Boolean Deposit (amount) Withdraw(Amount)


CM Generation shift : “From Entity to Object”From E/R Model to Object : ATM example

CustomerName : String

Amount

Date

1-20-N

Withdraw

AutomaticTellerMachine

ATM-Reference : StringCash : HiddenBank : StringTransaction : List[Money]History :List[Card-Nb,Acnt-Nb,Money

Bank-Card

Number : NatAccount-Nb: NatCode : String

Processes, operations and RulesATM-use : First enter-card – then enter-code – then enter-transaction— get money

- Read-card()- Enter-Pin(Code)- Enter-Amount(Money)- Get-Money(Money)

-Create()- Delete()- Accepted()- Rejected()

En

ter-cardE

nter-cod

een

ter-amou

nt

Get-m

oney

-Withdraw (ac, amount)- deposit (ac, amount)


CM Generation shift: “From Entity to Object”From E/R Model to Object : The Library Example

Student

Name : StringSubscription-NbSemester Date-Out

Date-Back

0-N0-3 Borrow

Book

Reference : StringName : StringAuthor : StringPublisher : String

Processes, operations and RulesFirst subscribe-- Get library-card – (Borrow – Return –or– Penality)*--(be)Unsubscribe(d)

- Add()- Suppress()- ToBorrow(Date)- ToReturn(Date)

- Subscribe2Library- Unsubscribe-GetCard- ReceivePenalty

Su

bscrib

eU

nsu

bscrib

eB

orrowR

eturn

Pen

ality


In real world terms:• An object represents an individual entity or

thing.• A class represents a group of objects that

exhibit some common characteristics or behavior.

• Classes are resulted from classification.

OO phylosophy : The real-world consists in a society of interacting objects.

• Examples of classes in real world:– Students– Graduate students– Undergraduate students – MS students– Ph.D. students

Object-Oriented Paradigm : General Overview


• An object has– state: defined by the set of fields or

attributes.– behavior: defined by the set of methods or

operation that can be applied to the object.– identity: determined at the creation time to

uniquely referencing the object.

• Class– A template for creating objects.– Objects of the same class exhibit the same

behavior. – But generally, they posses different states

(attribute values)

Object-Oriented Paradigm : Main concepts


Like in real world:

Book

one can

• Id : IF-43342• Title : „Petri Nets“• Author : „W.Reisig“• State :{available, borrowed, use..}

Object

has

Attributs (state)

Methods(behaviour)

• borrowed• returned• edited• .....

Object-Oriented Paradigm : Main concepts Object and Class


The class MyDate The object d is an instance

of class MyDate

MyDate d:MyDate fieldsday (or:,variables day = 31month state month = 1year attributes) year = 2000

set (d,m,y) set (d,m,y)incDays (nDays) methods incDays (nDays)getWeekDay ( ) getWeekDay ()

Object-Oriented Paradigm : Main concepts

object-class


The class Accounts Object Ac-Nasr instance

Account Ac-Nasr : Account

Number balance (fields, variables Number =

3130888limit state Balance = 1200history attributes) Limit = 20 History =

[20.2.2.07,…]

methods

+ open- Close- debit(amount)- Credit(amount- Tranfer(ac1,ac2)

Object-Oriented Paradigm : Main concepts Object-Class

+ openClose debit(amount)Credit(amountTranfer(ac1,ac2)


- Pin(Id)

debit(Id, Money)

- Balance(Bal) : Money

- Limit(Lm) : Money

- History(Hs) :List[M.D]

The Account Class

credit(Id, Money)

- Transaction(Tr)

- AcntNb(AcN)

- CardNb(AcN)

Insert_Code(InsC)(C)

- Store(Sr) : Money

- State(St) : State

The ATM Class

Insert-Card(InC)()

Choose_Trans(CTr)(M)

Object-Oriented Paradigm : Main concepts Encapsulation


• In general all attributes should be private. • Use EXCLUSIVELY methods such as debit

and credit to access the internal state. • Only methods that are part of the

“interface” should be public. • Instance variables and methods are

visibile within that object and other instances of the class.

• With respect to other objects and classes scope can be modified– private : accessible only within the

concerned class– protected : could be changed at subclasses– public : could be manipulated

everywhere

Object-Oriented Paradigm : Main concepts Encapsulation Principles


ENCAPSULATION

class MyDate { private int day, month, year; public void set (int d, int m, int y) {day=d, month= m, year= y … } public void incDays (int nDays) {. . .} public int getWeekDay ( ) { . . . }}

class OtherClass { void anyMethod { MyDate d = new MyDate ( ) ; d.set (09, 5, 2007) ; d.month = 3; // COMPILATION ERROR !!! }}

Object-Oriented Paradigm : Main concepts Encapsulation At-work


//without encapsulation:

circle k = new circle();k.radius = – 88;// radius negative!

//with encapsulationcircle k = new circle();boolean b =

k.setRadius(– 88);// radius never negative!

class circle{double radius, middlepointX, middlepointY;boolean setRadius(double newRadius){

if (newRadius > 0) {radius = newRadius;return true;}

else return false; }

}

Object-Oriented Paradigm : Main concepts Encapsulation At-work


A mechanism to organize classes by commonalities.– subclasses, specialization– superclass, generalization

• Is-a relationExample:

– A graduate student is a student.– A Master student is a graduate student.– A Ph.D. student is a graduate student.– An undergraduate student is a student.

Object-Oriented Paradigm : Main concepts Inheritance Concept


Student

GraduateStudent UndergraduateStudent

MasterStudent PhDStudent

Object-Oriented Paradigm : Main concepts Inheritance concept and illustration


Object-Oriented Paradigm : Main concepts Inheritance concept and illustration Running Account


+open (date, bank)-close(date)-Debit(Amount)-Credit(Amount)

Saving Account

Interest : PercentBalanceSav : Money

+open (date, bank)-close(date)- IncreaseInterest(Percent)- Money(money,account)


Object-Oriented Paradigm : Main concepts Inheritance concept and illustration (ordinary) book

NumberCode : NatTitle : StringStatus : {available, borrrowed.}NumberCopies : Natural

Toborrow (date)-ToReturn(Date)

ThesisFieldSupervisorMarkDate-defenseGetCoppy

Periodics

EditorsPublisher

Online-Publications

URLDurationsubscription

+subscribe- unsubscribe


Base

Derived

class Base { Base(){} Base(int i) {} protected void foo() {…}}

class Derived extends Base { protected void foo() {…} Derived(int i) { super(i);… super.foo(); }}

Object-Oriented Paradigm : Main concepts Inheritance at work


Overloading:• Two or more

methods/constructors with the same name but different numbers or different types of parameters:

void methodB(int i) void methodB(float f)

Overriding– Replacing the implementation of a methods

in the superclass with one of your own.– You can only override a method with the

same signature.

Please Avoid overloading !!!!

Object-Oriented Paradigm:Main constructions Overloading and Polymorphism concept


Object-Oriented Paradigm:Main constructions Overloading and Polymorphism concept

Polymorphism:• Inheritance creates an “is a”

relation:• For example, if B inherits from A,

then we say that “B is kind of an A”.• A same method same defined in the

class hierarchy• How to dynamically choose the right

methods ?


GuiComponent width:int height:int center:point setOptimalSize( ) moveTo(newX, newY)

Editbox Scrollbar

minValue text: String

maxValue getValue( ) append(String)

setOptimalSize( ) getText( )

Object-Oriented Paradigm:Main constructions Polymorphism concept


A subclass inherits all members of its superclass:

Variabls Methods

A subclass can: Add more variables Add more methods Override methods of its superclass

Scrollbar sb = new Scrollbar ( ) ; Q : What are the attributes (variables) of sb? What are the methods that sb can

execute?

Object-Oriented Paradigm:Main constructions Polymorphism at-work


GuiComponent g ; if (scrollbarWasSelected) g = new Scrollbar ( ) ; else g = new EditBox ( ) ;

g.setOptimalSize ( ) ; / / dynamic binding

• A reference to a superclass can point to objects

of its subclasses.• The pointer g is a polymorphic pointer.

Object-Oriented Paradigm:Main constructions Polymorphic Dynamic binding


GuiComponent [ ] ga = new GuiComponent [3] ; ga[0] = new Scrollbar ( ) ; ga[1] = new Scrollbar ( ) ; ga[2] = new EditBox ( ) ; for (int i=0 ; i<ga.length ; i++) { ga[i] . setOptimalSize ( ) ; //line 6}

Q: Which version of setOptimalSize is called in line 6?

Polymorphism allows us to work with an object

without knowing its exact type

Object-Oriented Paradigm:Main constructions Complex Polymorphic Dynamic binding


CASTING

class GuiComponent { void setOptimalSize ( ) { . . . } } class Scrollbar extends GuiComponent { void setOptimalSize ( ) { . . . } int getMinValue ( ) {. . . }

} guiComponent g ; g = new Scrollbar ( ) ;

Suppose we know that g currently points to a Scrollbar, and we want to call: n = g.getMinValue ( ) ;This will cause a compilation error (why?) …. Casting

problem

Object-Oriented Paradigm:Main constructions Polymorphism at-work (casting problem)


The solution is casting (actually down casting).

Casting = convert a variable from one type to another.

Down Casting = convert from a superclass to one of its subclasses.

sb = ( (Scrollbar) g).getMinValue ( ) ;

Or:Scrollbar sb = (Scrollbar) g ;sb.getMinValue ( ) ;

We “tell” the compiler that g currently points to a Scrollbar.

if g does not currently point to a Scrollbar, a ClassCastException is thrown.

Object-Oriented Paradigm:Main constructions Polymorphism at-work (casting problem)


C D

C D

association

aggregationwhole parta stronger form of association

C DcompositionIf an object d of class D is related to an object c of class C, then d depends existencialy on c.a stronger form of aggregation

C D directed association

Object-Oriented Paradigm:Main constructions Association Types


Association EndsC D Each object of class C is related

to 1 to 5 objects of class DEach object of class D is related to exactly one object of class C

1 1..5

C DEach object of class C is related to at least one object of class DEach object of class D is related to arbitrary many objects of class C

* 1..*

C D Associated objects of class D are ordered*

{ordered}

1..*



Line Point

roleused to navigate

0..1 2

lRole determine -pRole

association name

direction2 points determine a line

directed aggregation



Class Diagrams

C D

C D InheritanceClass C inherits from class D

dependency relationshipClass C depends on class D



Engine Brakes Wheel Searing Wheel

Car

1..1 1..4 41..1 4 1

Object-Oriented Paradigm:Main constructions Association Types : Aggregation


Conceptual Modelling of IS in UMLState-less and stateful DATA- Use Cases

- Class Diagrams

- Object Diagrams -Object Constraint Language

Processes and Rules- Sequence Diagrams

- Collaboration Diagrams

- State Diagrams

- Activity Diagrams- Component / deployment diagrams (implementation)

Stru

ctural asp

ectsB

ehavio

ural asp

ects

Forall C in ….


Information system

View-orientedsystem modelling

Airport Flight

Passenger

UML diagrams

partial views

Use case ArrivalIncludes Landing Description The plane is landing. Then the passengers deplane and the luggage is unloaded. If the passenger has luggage then the passenger claims its luggage.

Conceptual Modelling of IS in UML

. . . .


The origins of UMLUML resulted from the merging of three very popular OOD methods ----The three-Amigos

Booch’s OOD

Rumbaugh’s OMT

This focused on the external actors interacting with the system and their functional requirements.. A CASE tool called Objectory is available.

Booch’s method developed originally in 1991 based on OO Diagrams rather complex and CASE tool support essential. Theemphasis here was on design and implementation.

Object modeling technique supported by OMTool. Very Straightforward approach with an excellent text book. Widely adopted in academia and industry alike. Focus very much on analysis rather than design and implementation.

UML : Overview and History

Jacobson’s Use-Case approach


• A Conceptual Modeling– Used to describe a simplified (abstract)

view of reality – in order to facilitate the design and then

the implementation of object-oriented software systems

• Conceptual Language– UML is primarily a graphical language that

follows a precise syntax.• A UNIFIED

– As By the start of the 90’s there was a flood of modeling languages, each with its own strengths and weaknesses.

UML : Overview and History . . . What is UML


• In 1994 the UML effort officially began as a collaborative effort between Booch and Rumbaugh. Jacobson was soon after included in the effort.

• The goal of UML:– A comprehensive modeling language (all

things to all people) that– Promotion of the communication between

all members of the development effort.

• Version : UML 1.0 …. UML 2.0 (2003)

UML : Overview and History . . When is UML


• UML is a language– Conforms to specific rules.– Allows the creation of (structural, behavioural, and

functional) various models.– Does not tell which models need to be created.

• UML is a language for visualizing– UML is a graphical language.– Pictures facilitate communication (a picture is worth

a thousand words)• UML is a language for constructing and

understanding– UML supports both forward and reverse

engineering.• UML is a language for supporting analysis,

specification and design• UML is intended primarily for software-

intensive information systems

UML : Overview and History . . What is UML


• Diagrams: – Structural aspects :

» Class and object diagrams » Component and deployment (implementation)» OCL (object constraints language) for invariants,

pre- and post-conditions.– Behavioural aspects :

» Use cases, » Statechart, » Activity diagrams» Sequence diagrams

• A set of standardised diagramatic notations for representing different aspects of a (information) system. Containing static structural views, dynamic behavioural views and functional views

UML : Overview and History . . What is UML


The Unified Modelling Language

• A design method or process, neither is it a methodology. There is no provision for project management specification of deliverables or life cycle or provision for estimation

• Users, developers can uses - Whatever process and life cycle – RAD they want

- Focus on Prototyping / incremental development - Focus on waterfall or spiral - they wished and - Provide their own project management and QA framework.

UML : Overview and History . . UML is NOT


Static, structure diagrams• Class and instance diagrams

- These depict the components (classes or instances) within the system,- Their attributes and methods and their relationships with each other- The class diagram in particular is the most important single diagram in the design- Plus OCL constraints on invariants pre- and post-conditions

on methods• Component and subsystem diagrams (implementation) - How classes are grouped to form large assemblies - reusable components, sub-systems or packages of classes.• Deployment diagrams (implementation) - How the software components are deployed across a set of hardware components.

UML : Overview and History . . Inside UML


Interaction diagrams• Use-case diagrams - Show the interface between the system and the outside world - Identify the actors in the system and their required functionality.• Sequence diagrams - Capture the functionality of the system suing the messages passing between objects. - Each sequence diagram shows the implementation of one scenario• Collaboration diagrams - Based on the instance diagram, it shows how specific scenarios are implemented by message sequence. - Similar to sequence diagrams but with more detail



Dynamic behaviour of the system• Activity diagrams - Similar to Petri-nets, - Provide a view of the way objects interact and changes their states in consequence - The emphasis here is on system functionality as perceived by users• Statecharts - Harel Statecharts are developed from finite state notation - Illustrate the dynamic behaviour of objects. i.e. the way in which an object evolves through time - in response to external events.



Most diagram types are involved, but principally at the conceptual level :

1. Conceive a use-case diagram - identify actors

- identify major functional requirements2. Conceive an initial Class diagram

- discover principle classes - represent important relationships

3. Event sequence diagrams - Examine possible object interactions - Determine class protocols At Implementation model different refinements are to undertake - combining or splitting classes, - adding or removing relationships, -defining the implementation of relationships, - introducing generalisations, interfaces - Introduce Component, sub-system and deployment models.

UML : Overview and History . . UML for IS


A use case ... – Specifies what system will be used for, before the

defining what system is supposed to do– Describe functionality of a system yielding observable

results– Details scenarios that describe the interaction/dialog

between users of the system and the system itself. Identify who (or what) interacts with the system

– Does not indicate how the specified behavior is implemented, only what the abstract behavior is.

– Performs a service for some users of the system.» A user of the system is known as an actor.» An actor can be a person or another system.

– During the conceptual phase » Facilitates communication between the users and

developers of the system.» Facilitates the goal-based understanding of the

system

UML : Use Cases Overview and illustrations


UML : Use Cases Basic artifacts

An Actor is consistent set of roles that user plays when interacting with the system (e.g. a user or outsider of the system that interacts with the system)

Actor Relationship UseCaseName

A link between the actors and the functions (use-cases). Different relationships are possible.

A Use Cases a sequence of actions performed by a system that yields a valuable result for a particular actor


UML : Use Cases basic artifacts

System defines the boundary between the system and the actors interacting with the system and other systems

System


• Model with use cases essencial parts of system functionality

• Model only those actors who involved in Use Cases

• Factor out common functionality using inheritance relationship <<include>>, <<extend>> stereotypes

• Describe only those events which are visible for the actor

• Each use case should describes a significant piece of system usage understandable by domain experts

• Use nouns and verbs accurately to help deriving objects and messages for interaction diagrams afterwards

UML : Use Cases---Modelling guidelines


Specifies the participation of an actor in a Use Case

ActorUse Case

Association

Generalization

A taxonomic relationship between a less and a more general Use Case



<<extend>>

Extend a relationship

Specifies how the behaviour of the extension use cases e can be inserted into the behaviour of the base use case b

<<include>>

specialize a relationship

Specifies how the behaviour of the included p contributes to the behaviour of the base use case b

e b

pb



Student

Deposit funds

Prepare for examination

Louis acts as a student

Enroll for a course

Elen acts as a student

UML : Use Cases actors illustrations


Student

Deposit funds

Prepare for Examination

Louis acts as a student

Enroll for a Course

Louis acts as a customer

customer

UML : Use Cases actors illustrations


Ask the following questions:

– What are the primary tasks that the system is supposed to perform?

– What data will the actor manipulate (add, store, change or remove) in the system?

– Which external changes does the system need to know about?

– Which changes or events will the actor of the system need to be informed about?

UML : Modeling scenarios with Use Cases


To model the requirements of a system …– Identify all actors (users of the system).– Identify the needs, from the system, of each

individual actor.– Make each need a use case.– Identify redundant behavior within your set

of use cases, and factor it into common base-class use cases ( generalization ) .

– Do the same for actors.– Show the relationships between actors and

use cases.

UML : Modeling scenarios with Use Cases


– Show a set of actors, use cases, and their relationships.

– Facilitate communication between non-technical customers and developers due to their simplistic nature.

– Show the functionality of the system from the prospective of each user of the system.

– Model the context of the system.– Model the requirements of the system.

Use case diagrams …

UML : Use Cases concepts


• Use case Arrival• Includes Landing• Actors plane, passenger• Preconditions non• Description The plane is landing.

Then the passengers deplane and the luggage is unloaded. If the passenger has luggage then the passenger claims its luggage.

UML : Use Cases --- AIRPORT illustration


ArrivalPassenger

Departure TakingOff

Landing Plane

<<include>>

Airport

Flight

use caseuse case

actoractor

<<include>>

UML : Use Cases --- AIRPORT illustration


Bank Consortium

Deposit

Withdraw Cash

Automated Teller Machine (ATM)

Transfer Funds

Maintain ATM MaintenanceCrew

Customer

UML : Use Cases --- ATM use illustration


Use-case for library system

Returnbook

Staffborrower

studentborrower

Checkmember status

Reservebook

Browsecatalogue

Borrowbook

browser

Counterstaff

manager

Registermember

Usagereport

Updatecatalogue

Return late book

<<uses>>

<<uses>>

<<extends>>

UML : Use Cases --- Library illustration


• Class diagrams are the most commonly used diagrams in UML

• Class diagrams are for visualizing, specifying and documenting the system from a static perspective

• Class diagrams indicate which classes know about other classes and, if they do, – what type of relationship exists

UML : Class Diagrams Overview


• Class diagrams will have different levels of detail (abstraction) depending on where we are in the software development process

• Class diagrams commonly contain classes, interfaces, collaborations and associations

• Class diagrams help in showing the functional requirements of the system - the services the system should provide to its end users

UML : Class Diagrams Overview


• To model a collaboration (a group of classes working toward a common purpose) …– Use scenarios (modelling by example) to see which

classes are actually involved in carrying out a particular operation.

» Scenarios will also aide in establishing relationships between classes.

– Fill in the ‘responsibilities’ section of each class icon.» The responsibilities of each class will eventually

evolve into actual attributes and behaviors.– A complex system typically requires multiple class

diagrams.» Each diagram is devoted to a particular

functionality of the system.

UML: Class Diagrams---Modelling Guidelines


• Multiple class diagrams are required to model large systems.

• Each individual class diagram …– Shows a single aspect of the system.– Contains only elements that are

essential to understanding that aspect.– Provide details consistent with its level of

abstraction.– Uses meaningful class and member

names• Pointers to other classes are modeled as

associations



• A well-defined class is:– loosely coupled (few entry points) and – highly cohesive (all members toward one

functionality)• Ask yourself “Am I trying to show what

the class does or how it does it”. – That will tell you at what level of abstraction to

model the class.• In the requirements and specification

phase you are interested in “what”. – In the design phase you are interested in “how”.

• Don’t hesitate to attach notes to the class icons – if further clarification is necessary.



UML : Class Diagrams---Illustration


The UML recognizes four principle relationships between classes as follows :- Simple association - usually annotated and interpreted left to right/top to bottom. use small arrows to indicate.

Aggregation - ‘a part of’ relationship Composition - a stronger - permanent ownership form of aggregation.

Generalisation/specialisation – ‘is a’ or ‘is like as’ relationship.

course

student

is enrolled on

race car*

car wheel4

vehicle car

UML : Class Diagrams---Association types


Other forms of notation frequently used are :-

Role names on associations

Interface inheritance (implements)

Uses relationship:

Generic instantiation :

employee

works for

boss

worker*

0,1

<<interface>>Controls

simulator

Flight modelmaths

controls

collection

type

Book list

<<bind>> book

UML : Class Diagrams---Association types


During the conceptual modelling phase:• the conceptual class diagram model is developed • through the following stages :-

Simple class names with relationships

Introduction of class attributes

Introduction of methods

During design the design phase, (1) attribute and method detail will be extended to include visibility indication,(2) data types, parameter and parameter types and return types from methods.

Book

Book

authortitle

Book

authortitle

lendreturnreserve

UML: Class Diagrams--Attributes / Methods


UML : Class Diagrams concepts Compacted


• Visibility– Class members (attributes and behaviors) may be

specified as public (+), private (-) , or protected (#).– Restricting visibility is the same as restricting

accessibility.» limiting the number of entry points into an object.

• Scope– Individual member data (attributes) may have either

class scope or instance scope.– Class scope - A single copy of an attribute is shared

by all instances of a class (underline the attribute)» productCount : int » In C++ : static int productCount

– Instance scope - Each instance of a class would have its own copy of the attribute.

» All attributes have instance scope by default

UML: Class Diagrams—Visibility and Scope


UML: Class Diagrams—Visibility and Scope


• Abstract– A abstract class cannot have any

direct instances.– Not all OO programming languages

directly support abstract classes. – An abstract class is thought to be so

general as to be useless by itself.– Abstract classes only occur in the

context of an inheritance hierarchy. – In UML you specify that a class is

abstract by writing its name in italics.

UML: Class Diagrams — Abstract / Polymorphism


• Polymorphism– Polymorphic behavior exists in the

context of inheritance.– Polymorphism applies to behavior

(member functions) only.– Polymorphism is synonymous with

dynamic binding.– In UML a behavior name in italics is

used to indicate polymorphism.

UML: Class Diagrams — Abstract / Polymorphism


UML: Class Diagrams —Abstract / Polymorphism


• Multiplicity– Class multiplicity

» In UML it can be indicated by placing a number in the upper right corner of the class icon.

» Most commonly expressed in the context of associations between classes.

– Attribute multiplicity» In UML it is indicated as an

expression appearing in square brackets just after the attribute name.

UML: Class Diagrams-More Concepts-Multiplicity


• Attributes– May be expressed using various levels of

detail.– The syntax for an attribute is

» [visibility] name [multiplicity] [: type] [ = initialValue ] [{propertyTag}]

– There are three predefined property tags»changeable - the attribute may be read

and modified (default)»addOnly - when multiplicity > 1,

additional objects may be added but not removed

» frozen - read only (constant value)– The only feature of an attribute that is

required in a class icon is its name.

UML: Class Diagrams --More Concepts-Attributes


• Operations (behaviors)– May be expressed using various levels of detail.– The syntax for an operation is

» [visibility] name [(parameterList)] [: returnType] [{propertyTag}]

– Predefined propertyTags are ... » isQuery - cannot change the state of the object.» Sequential - only one thread of control in the object at

a time.» Guarded - pretty much the same as sequential» concurrent - multiple threads of control may be in the

object simultaneously.

– Each parameter has the syntax: » [direction] name : type [= defaultValue]» Directions may be in, out, or inout.

– The only feature of an operation that is required in a class icon is its name.

UML: Class Diagrams-More Concepts-Operations


• Templates are ...– A parameterized element, intended to

facilitate software reusability.– Used to automate the creation of class

definitions.– Essentially a class definition with the data

types of certain attributes yet to be defined.– Most commonly used to create container

classes.– Represented in UML as a dashed box in the

upper right-hand corner of the class icon, which lists the template parameters.

UML: Class Diagrams —More Concepts-Template


UML: Class Diagrams —More Concepts-Template


• A classifier is a mechanism that describes:– Structural and – Behavioral features.

• Types of classifiers are …– classes, interfaces, datatypes, signals,

components, nodes, use cases and subsystems.

• Classes are the most important kind of classifier.– Classes have a number of features

»beyond attributes and behaviors» to model some of the more

subtle/advanced features of a system.

UML: Class Diagrams—Advanced classifiers


Other classifier definitions:– Interface -A collection of operations that are

used to specify a service of a class or component– Datatype - Modeled as a class with the

strerotype <<type>>. May be primitive or user-defined.

– Signal - A class used for communicating information. The class in its entirety is a kind of message.

– Component - A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces

– Use case - A description of a set of a sequence of actions that yields an observable result of value to a particular actor.

– Subsystem - A grouping of element that carry out a subset of the entire systems functionality. Modeled as a package with the stereotype <<subsystem>>


Rigoros and Adaptive... Service-Driven Applications1 Development of Rigorous Adaptive Information...

Documents

Transcript of Rigoros and Adaptive... Service-Driven Applications1 Development of Rigorous Adaptive Information...