Communications Software Engineering Analysis Model

Transcription

1 Communications Software Engineering Analysis Model Wolfgang Emmerich 1 Lecture Overview Aims of Analysis Model Building on outputs of Requirements Model Basic UML notations Introduction of new types of analysis objects Reuse of use cases Inputs for Design Model 2

2 Stages of Development Process User Reqs System Reqs Detailed Design Coding System Integr. Archit. Design Pre-Prod. Test Project and Risk Management System Management Version and Configuration Management Quality Management 3 System Reqs Document Owner: Chief Business Analyst 1 UML Use Case Model (Rose) + 2 UML Interaction Diagrams (Rose) + Analysis UML Sequence Diagrams Model UML Collaboration Diagrams 3 UML Analysis Class Diagram (Rose) + 4 User Interface Prototypes (GUI Tools, Office) * 5 Specification of Report Format (Office) 6 User Manual (Office) User Reference Manual User s Guide 4

3 Aims of the Analysis To provide a logical model of the system, in terms of : classes, relationships How to get the thing right, now and in the future 5 Producing an Analysis Model Inputs Actions 10 Draft initial class diagram 11 Re-examine use case and object behaviour 12 Refine class diagram 13 Execute check 14 Revise class diagram 15 Group classes into packages Outputs Notations 6

4 Analysis Input and Outputs Inputs: uses cases and use case model problem domain object list Outputs: class roles and responsibilities [text] use case description in terms of classes and operations [text x use case] completed analysis model [class and package diagrams] 7 Notations Class (rectangle containing name, attributes, operations) Object (rectangle plus obx:cx) Association (by value/aggregation, cardinality/multiplicity) Generalisation (UML term replacing OOSE inheritance ) Package Depends association 8

5 CLASSES IN UML classname attribute name: type Op name (parameter: type): result type Polygon centre: Point vertices: List of Point bordercolour: Colour fillcolour: Colour display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean classname Polygon 9 Objects in UML objectname: classname attribute name: type = value (same operations for all instances of a class) objectname: classname triangle1: Polygon centre = (0,0) vertices = (0,0), (4,0), (4,3) bordercolour: black fillcolour: white display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean triangle1: Polygon 10

6 UML Generalization SUPERCLASS Staff Member Librarian Lecturer Researcher SUBCLASS SUBCLASS SUBCLASS Handler KeyboardHandler MouseHandler JoystickHandler 11 Associations in UML bidirectional / binary unidirectional aggregation composition association name [+ single directional arrow] role name multiplicity role name multiplicity supplementary characteristics 12

7 Composition vs Aggregation Composition class Address { char *street; char * plz; } class Person { char * name; Address adr; } Person p = new Person() Aggregation class Address { char *street; char * plz; } class Person { char * name; Address *adr; Person(){ adr=new Address(); } Person p=new Person; 13 Association Examples in UML User authorised on > 1..* 1..* Workstation Authorisation priorities privileges AttributesOfClass OperationOfClass 1 1 ClassDecl start session() 1..* home directory 1 Directory 1..* 1..* Attribute Operation 14

8 Class Diagrams in UML Class diagrams : show logical, static structure of system provide core of unified model Generation of initial class diagram from problem domain object list classes of objects associations / attributes generalization relationships 15 A Recycling Machine Class Diagram Deposit Item Name Deposit value $Daily total Receipt Total cans Total bottles Total crates Can Width Height Bottle Neck Length Bottom Crate Width Height Length Customer panel Operator panel 16

9 Exploiting Use Cases Employ classes and use cases, one by one, to describe roles and responsibilities of each class to distribute behaviour specified in use cases to ensure that there is a class for every behaviour 17 Roles of Classes in OOSE Interface classes - for everything concerned with system interfaces Entity classes - for persistent information and behaviour coupled to it Control classes - for functionality not normally tied to other classes << interface >> << entity >> << control >> interface name entity name control name Integrated into UML as stereotypes: 18

10 Interface Classes Contain functionality directly dependant on system environment Definitions focus on interaction between actors and use cases Receipt Receiver Receipt Printer Operator Panel Customer Customer Panel Alarm Device Operator 19 Associations between Interface Classes Definition of both dynamic and static associations << interface >> Receipt button << interface >> Receipt Printer Operator Panel << interface >> Customer Panel Crate slot << interface >> Can slot Customer Panel << interface >> Alarm Device Bottle slot 20

11 Attributes of Entity Classes Purposes of entity classes : To store information persisting after completion of a use case To define behaviour for manipulating this information << entity >> Deposit Item Name: String Deposit value: ECU $Daily total: Integer << entity >> Can << entity >> Bottle << entity >> Crate 21 Entity Communication A primary task to identify associations involving communication modelling of communication between objects shows the sending and receiving of messages as stimuli starts from object initiating communication directed to object where reply generated or operation executed Receipt Basis Deposit Item 22

12 Entity Operations Defining entity operations for: storing and fetching information creating and removing object behaviour that must change if entity object is changed << entity >> Deposit Item Name: String Deposit value: ECU Daily total: Integer Create () setvalue (integer) Increment () 23 Control Classes Control classes needed to provide for: behaviour not natural in interface and entity classes 'glue' between other classes in use case typical control behaviours improved maintainability report generator information administrator deposit item receiver extends alarm device 24

13 Use Case View Model each use case Describe use case in terms of classes Customer Panel Deposit Item Receiver Receipt printer n Receipt Basis Deposit Item Can Bottle Crate 25 An elaborated Use Case When the customer returns a deposit item the Customer Panel s sensors measure its dimensions. These measurements are sent to the control object Deposit Item Receiver which checks via Deposit Item whether it is acceptable. If so, Receipt Basis increments the customer total and the daily total is also incremented. If it is not accepted, Deposit Item Receiver signals this back to Customer Panel which signals NOT VALID. When the Customer presses the receipt button, Customer Panel detects this and sends this message to Deposit Item Receiver. Deposit Item Receiver first prints the date via Receipt Printer and then asks Receipt Basis to go through the customer s returned items and sum them. This information is sent back to Deposit Item Receiver which asks Receipt Printer to print it out. 26

14 Packages Packages are a way to decompose class diagrams into manageable units Packages are necessary: because of large numbers of classes to provide optional functionality to minimise effect of change 27 Packages (Cont d) Packages should have a: tight functional coupling inside weak coupling outside indicated by 'dependency associations between packages Packages may: contain nested packages with service packages as atomic parts have individual classes outside be result of organisational or managerial pressures 28

15 Recycling Machine Packages Main Alarm Receipt printer Deposit Administration 29 Deposit Package in UML Deposit << interface >> Receipt button << interface >> Crate slot << interface >> << control >> Deposit Item Receiver << entity >> Receipt basis << entity >> Deposit Item Name: String Deposit value: ECU Daily total: Integer << interface>> Receipt printer::printer << control >> Alarm::Alarmist << interface >> Can slot Customer Panel Create () setvalue (integer) Increment () << interface >> Bottle slot << entity >> Can << entity >> Bottle << entity >> Crate 30

16 Analysis Model Outputs: class roles [text] use case description in terms of classes and operations [text x use case] completed analysis model classes [diagram] sub-system diagrams [package diagram] Notations introduced: class, object, associations (binary, unidirectional, aggregation, generalisation) stereotypes (classes, associations) package (+ dependency association) 31 Analysis in OOSE - Summary USER PERSECTIVE Actors and Use Cases Strong emphasis on requirements modelling Resistence to effects of change ADVANTAGES OVER OTHER METHODS Ways to identify and define classes and objects Effective and useful identification of roles of classes Recognition of user role (and interface) Refined with practical use 32

17 Modelling Processes 33 Processes and Threads Execution of a program is a process Concurrent programs consist of multiple processes Threads are lightweight processes Both threads and processes can be modelled in the same way We use finite state machines for that 34

18 Labelled Transition Systems Special form of finite state machines Used to model states of concurrent programs and transitions between them LTS:=(S,T,A,δ,c) where S (a finite set of states) T S S (a finite set of transitions) A (an alphabet of atomic actions) δ: T A (a transition labelling) c S (the current state) 35 Graphic LTS Notation 0 Current State scratch scratch n abc States Transitions Labels think talk scratch talk think 36

19 LTS Semantics All actions that are annotations of transitions starting from the current state are enabled If process engages in enabled action target of transition becomes current state Demo In this way LTS determines all possible traces of process 37 Finite State Processes (FSP) LTS become unmanageable for large number of states and transitions Process algebras determine LTSs in a more concise way Finite State Processes (FSP): machine readable notation for a process algebra For each FSP model an equivalent LTS can be constructed automatically 38

20 FSP Intro: Action Prefix Let x be an action and P a process. The action prefix(x->p) is process that initially engages in action x and then behaves in the same way as process P Used to model atomic actions Actions have lower case identifiers, states have upper case identifiers Example: ONESHOT=(once->STOP). once Equivalent LTS: FSP Intro: Recursion Let P be a process. Then P may be used in action prefixes in a recursive way. Used to model repetitive behaviour Example: SWITCH=OFF. OFF =(on->on). ON =(off->off). on Equivalent LTS: 0 1 Note: Processes are equivalent to states off 40

21 FSP Intro: Local Processes It is not necessary for all states/processes to be globally visible. Restricting states/processes by use of, Example: SWITCH=OFF, OFF=(on->ON), ON=(off->OFF). OFF and ON are not visible outside SWITCH Equivalent to: SWITCH=(on->off->SWITCH). 41 FSP Intro: Choice (x->p y->q) describes a choice that engages either in x or y. After x it contin-ues with P, after y it continues with Q Example: DRINKS=( red->tea->drinks blue->coffee->drinks ). Equivalent LTS: red 0 1 tea blue coffee 2 42

22 FSP Intro: Indexes A range type is a finite and scalar type: Example: range T=0..3 If T is a range type then x[i:t] is the declaration of an action index and P[i:T] is declares an indexed process. A process index variable is valid within the process, an indexed action is valid within the scope of the choice. 43 range T=0..5 X=X[0], X[i:T]=(inc->X[i+1]). 44

23 FSP Intro: Index Example const N =1 range T =0..N range R =0..2*N SUM =(in[a:t][b:t]->out[a+b], OUT[s:R]=(out[s]->SUM). Equivalent LTS: in.1.1 in.0.1 in out.0 out.1 in.1.0 out FSP Intro: Guarded Actions The guarded action when B x->p means that when the guard B is true action x is enabled and the process proceeds as P. Example: COUNT(N=3) =COUNT[0], COUNT[i:0..N]=(when(i<N) inc->count[i+1] when(i>0) dec->count[i-1] ). Equivalent LTS: inc 0 1 dec inc dec 2 inc dec 3 46

24 Summary Formal Definition of LTS Algebraic notation in FSP Equivalence between LTS and FSP FSP and LTS concepts introduced so far are sufficient for sequential programs Next session: FSP constructs for modelling concurrent programs 47 Modelling Concurrency in FSP 48

25 What do we have to model? Relative or absolute speed? Neither! Concurrency or parallelism? Interleaved model of concurrency! Relative order of actions? Arbitrary interleaving! We use an asynchronous model of execution! 49 FSP: Parallel Composition If P and Q are processes then (P Q) denotes the parallel execution of P and Q is used to model parallel composition of processes Names of concurrent processes are preceeded by Example: CONVERSE =(think->talk->stop). ITCH =(scratch->stop). CONVERSE_ITCH =(ITCH CONVERSE). 50

26 Equivalent LTSs CONVERSE =(think->talk->stop). think talk ITCH=(scratch->STOP) scratch 1 CONVERSE_ITCH =(ITCH CONVERSE). scratch scratch think talk scratch 0,0 1,0 2,0 2,1 1,1 0,1 talk think 51 Properties of Parallel Composition Parallel composition operator has two important algebraic properties Commutativeness (P Q)=(Q P) ordering is not important! Associativeness ((P Q) R)=(P (Q R))=(P Q R) brackets can be omitted! 52

27 FSP: Process Interactions Concurrent processes that share actions interact with each other Used to model synchronisation Example: MAKER = (make->ready->maker). USER = (ready->use->user). MAKER_USER = (MAKER USER). Product has to be ready before it can be used. 53 Equivalent LTS MAKER = (make->ready->maker). USER = (ready->use->user). MAKER_USER = (MAKER USER). make ready make Demo use use 54

28 Handshake An action that is acknowledged by another action is referred to as handshake Widely used to structure process interactions Example: MAKERv2=(make->ready->used->MAKERv2). USERv2 =(ready->use->used ->USERv2). MAKER_USERv2 = (MAKERv2 USERv2). LTS: 0 make ready use 1 2 used 3 55 FSP: Process Labelling The process label a:p prefixes each label in the alphabet of P with a Avoids name clashes in different instantiations of processes and enables reuse. Example: SWITCH = (on->off->switch). TWOSWITCH=(a:SWITCH b:switch). Alphabet of TWOSWITCH: {a.on, a.off, b.on, b.off} 56

29 FSP: Process Labelling (cont d). The process label {a1,..,ax}::p replaces every label n in the alphabet of P with label a1.n,,ax.n. Example: RESOURCE=(acquire->release->RESOURCE). USER = (acquire->use->release->user). RESOURCE_SHARE = (a:user b:user {a,b}::resource). 57 Equivalent LTSs 0 a:user a.acquire a.use 1 2 a.release {a,b}::resource a.acquire 0 b.acquire 1 a.release b.release a:user b:user {a,b}::resource b.acquire 0 a.acquire a.use 1 2 a.release b.release b.use

30 FSP: Relabelling Relabelling functions change names of action labels. The relabelling function is: /{new1/old1, newn/oldn}. Used to synchronise actions with different names in composite processes. Example: CLIENT=(call->wait->continue->CLIENT). SERVER=(request->serve->reply->SERVER). CLIENT_SERVER = (CLIENT SERVER) /{call/request, reply/wait}. 59 CLIENT=(call->wait-> 0 call wait 1 2 continue Equivalent LTSs request serve continue->client) reply SERVER=(request->serve ->reply->server). CLIENT_SERVER = (CLIENT SERVER) /{call/request, reply/wait}. 0 call serve reply 1 2 continue 3 60

31 FSP: Hiding The hiding operator \{a1..ax} removes action labels a1..ax from alphabet of P and hides them Hidden actions are labelled tau Hidden actions in different processes are not shared Example: USER=(acquire->use->release-> USER)\{use}. 61 FSP: Interfaces The interface hides all actions in the alphabet of P that do not occur in the set a1..ax. Complementary to hiding Like hiding used to reduce complexity of resulting LTS. Example: USER = (acquire->use->release-> USER)@{acquire,release}. 62

32 FSP: Structure Diagrams Process P with alphabet {a,c,x} a P c x Parallel Composition (P Q)/{m/a,m/b,c/d} P a c x m c x b d x Q Composite Process S = (T U)@{x,y} x T a U S y 63 Summary Parallel Composition Process Interactions Process Labelling Process Relabelling Hiding / Interfaces Structure Diagrams Solve Exercises of tutorial sheet 64