2. - 1 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the form of: “A system to do/be/achieve X” Example: A system to generate birth certificates A system to generate reusable components A system to provide a uniform computing platform across government agencies All these may actually refer to the same application software!

3. - 2 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Software Development is a form of System Development System Development entails the processes of: Finding out what is the problem Arriving at a solution Delivering on a good solution Discovery Invention Construction

4. - 3 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Analysis Design Implementation So “analysis and design” is all about identifying what the problem is and to propose one or several solutions to rectify the problem. What is the problem? What is a solution? How do we deliver on a good solution? Discovery Invention Construction

5. - 4 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Figuring out the problem. The problem that is to be figured out is immersed in the real world. The real world (the problem situation) is a web of interactions of amazing complexity To have a chance, we need to be able to focus only on what is: RELEVANT

6. - 5 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design We need therefore to concentrate on: Those elements about which we need to ask questions, Those elements about which we need to answer questions We also need to make sure that: Only those elements that are of our direct and immediate concern are focused on at any one time.

7. - 6 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The first of these is called: The second is called: CONTEXTUALIZATION ABSTRACTION

8. - 7 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Once we have understood the problem, we need to: Communicate our understanding: To ourselves at a later time To others To do so, we need to capture, retain and communicate what is relevant and in context. This is called Modeling

9. - 8 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Modeling is therefore a fundamental element of analysis and as such a vital part of software development. In order to capture, retain and communicate what is needed, the modeler has to use a language. This is called: The Modeling Language The modeling language has to contain the vocabulary and the grammar of the modeling approach utilized.

10. - 9 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Activity 1 Model a Person

11. - 10 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Activity 2 Model a Refinery

12. - 11 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design What’s there? How does it happen? When does it happen? (or in what sequence?) Things and static relationships Change Order and timing of change

13. - 12 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Things and static relationships Change Order and timing of change Structure Transformations Causal (sequential) relationships For all deterministic systems we must capture all that is relevant of these three aspects, if we are to have sufficient understanding of them.

14. - 13 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design System Modeling In SE, we have an array of notations and diagrams for modeling in each of these three views. Structure Modeling Entity Relationship Diagrams, Formal Structural Models (e.g. Z, Object Z or VDM), Class Diagrams,… Transformational Modeling Transformational Relations(Functional Specification), Activity Diagrams, Data Flow Diagrams (with specification), Flow Charts, … Causal (Dynamic) Modeling Sequence Diagrams, Collaboration Diagrams, State-charts (State Transition Diagrams), Petri-nets, Entity Life Histories,…

15. - 14 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Structure modeling is modeling of things and their situational relationships. A photograph is a good structure model. It shows things that were there when the picture was taken and how they were situated with respect to one another. We can similarly compose diagrams or other models of a problem situation in which we depict all the relevant things and relationships. There are many ways to do this. We shall discuss the three most popular and prevalent of these. Namely: Entity Relationship Modeling which is used mainly for database design Formal Schemas and Formal Object Schemas (using Z and Object Z) Class Diagrams (using UML) used mainly as part of object oriented modeling Structure Modeling

16. - 15 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Entity Relationship (ER) Modeling: This is an informal (or semi-formal) approach to structure modeling in which a situation is studied so that static and persistent elements in it are identified, along with their static relationships. A collection of like elements is called an entity. A mapping of elements of one entity onto another entity (or itself) is called a relationship. Entities are defined in terms of a name and a set of attributes. Relationships are defined in terms of a verb phrase (e.g. works-for) that establishes the nature of the mapping between the entities. The results of ER modeling are almost always shown using diagrams. There are many different conventions. In the absence of an industry standard, we use a popular one here of my preference. Structure Modeling

17. - 16 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: Employee Name: SSN: Salary: Department Name: Location: Budget: Works-For m 1 This means that there are many elements belonging to the set Employee (i.e. many persons employed) each is mapped into (has a relationship with) only one element belonging to the entity Department (a specific department). The relationship is that this particular employee works for one specific department. For each employee we keep his or her name, social security number and current salary. For each department we keep the name of the department, its location and its budget. You will learn (or may have already learned) a lot more about this modeling approach in your database course. Structure Modeling

18. - 17 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Formal Object Schemas: Object Z Stack[T] max : N items: seq T #items  max INIT items = ‹ › Push  ( items) #items < max items’ = ‹ item? › ⁀ items item?:T Structure Modeling

19. - 18 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Pop  ( items) item!  ‹ › items = ‹ item! › ⁀ items’ item!:T top  ( items) item!  ‹ › items’ = items item!:T Structure Modeling

20. - 19 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design There are many different approaches to causal modeling. Whilst they all attempt to do the same thing, they are not all of the same level of capability, formality, ease of use or learnability. In this course we cover a number of popular approaches to causal modeling, including: Entity Life Histories The UML suite of dynamic modeling facilities, which include Petri-nets Sequence diagrams Collaboration diagrams State diagrams Causal Modeling

21. - 20 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Entity Life Histories These are diagrams that depict the various states of a class or type of object from inception to demise. Usually used in relation to persistent database “entities”, they can become overwhelmed if the states are too numerous or the object can possess concurrent states. They also do not necessarily depict the events that lead to state transitions. EMP CREATE INIT UPDATE REPORT RETIRE ARCHIVE * * Causal Modeling

22. - 21 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Petri nets: Petri nets are a formal graphical approach to causal modeling. They improve on the capabilities of state diagrams by allowing for proper description of some major issues in concurrency such as synchronization, deadlocks and conflicts. Petri nets are composed of two types of nodes and one type of arc. The two types of node are called places and transitions. The arc is called an event. A fourth artifact called a token, when located inside a place, marks it as enabled. Causal Modeling

23. - 22 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A token ( ) inside a place indicates that the place has satisfied all pre- conditions for causing an event to occur. Such a place is called “enabled” p1 p2 p3 p4 p5 t1 t2 t3 A Petri net composed of five places P={p1,p2,p3,p4,p5} and three transitions T={t1,t2,t3} A transition takes place only when all places leading to it are enabled. Such a transition is called an enabled transition. Causal Modeling

24. - 23 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The system stops here. A transition takes place to p2. But t2 is not enabled as p3 is not enabled. p5 p1 p2 p3 p4 t1 t2 t3 P1 is enabled, thus enabling t1 Causal Modeling

25. - 24 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design p5 p1 p2 p3 p4 t1 t2 t3 Causal Modeling

26. - 25 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design p5 p1 p2 p3 p4 t1 t2 t3 p’1 p’2 p’3 p’4 t’1 t’2 t’3 Conflict ? Causal Modeling

27. - 26 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design p5 p1 p2 p3 p4 t1 t2 t3 Deadlock ? Causal Modeling

28. - 27 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Transformation modeling is the third modeling view. It answers the question “how”. Depending on level of granularity there are many techniques. Including: Abstraction Level: Dataflow Diagrams Activity Diagrams Low Level: Pseudo-code Flowcharts etc. Not part of UML Transformational Modeling

29. - 28 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Flow charts Flow charts depict the flow of control. They show how operations are performed and decisions made by depicting how the control in the program is exchanged from the beginning to the end of all paths of interest. Flow charts show how the program works. Flow charts are composed of a number of node types and one type of arc. The node types are: Start/End nodeTransformation nodeDecision node Link nodeSpecial processing nodesLogic nodes Transformational Modeling

30. - 29 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Flow charts can be high level or low level High level flow charts depict the flow of control at a high level of granularity, such as the organization or the entire system. Low level ones usually depict the flow of control in a specific program unit. The difference between a high level and low level flow chart is that in a low level flow chart all transformational nodes contain transformations that can not be usefully broken down to simpler flowcharts themselves. By this we mean doing so would produce transformation at a lower level of granularity than that of the target programming language. Transformational Modeling

31. - 30 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Flow chart nodes: Start/End nodes: These mark the beginning and end of a flow within a flowchart Transformation nodes: These show a logical step taken Terminator Transformation Alternate transformation Manual transformation Transformational Modeling

32. - 31 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Decision nodes: These show alternate conditions or paths the flow may take Link nodes: These connect various parts of the diagram (e.g. continue on next page) Logic nodes: These are logical operators such as AND, OR and NOT Condition AND OR NOT On page connector Off page connector Transformational Modeling

33. - 32 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Special processing nodes: These are nodes that depict specific large scale processing or machine interaction. Useful in the early days when flowcharting was amongst the only modeling methods available, they are now largely disused. Manual input Disk Other mag. storage Stored data Punched tape Punched card Seq. Access device Console or display Extract Merge Sort Collate Internal storage Delay Transformational Modeling

34. - 33 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Start End Read N N>0 T F Read A,B A=A+B N=N-1 N=0 F T Write A Transformational Modeling

35. - 34 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Data Flow Diagrams Data flow diagrams depict the flow of data. They show how data received as input is changed to outputs by the various operations performed. Data flow diagrams show how the data changes. Basic data flow diagrams are composed of a number of node types and one type of arch. The node types are: External Entities (Sources and Sinks)Processing node Data-storesLink nodes Transformational Modeling

36. - 35 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design External entities (sources and Sinks): These are entities outside the scope of our focus that provide the inputs from the outside or receive the outputs generated. They are labeled by a noun or an object or class name. Process nodes: These depict the processing that is done to the inputs into that process to form the output. Usually these nodes are labeled by a verb phrase representing the nature of the processing to be done and a number sequence depicting the process and its level Customer Book seat 1.4.7 Transformational Modeling

37. - 36 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Data-stores: These are buffers where interim outputs generated are stored for future usage. Data-stores are usually named. Link nodes: They connect the various parts of the diagrams to yield a less cluttered result. They are usually numbered or carry a symbol. Primary Buffer The only arc is called a dataflow and it depicts the flow of data (as input into or output from) an external entity or process. They are usually named. client address 22 Transformational Modeling

38. - 37 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example DFD 1.2.1 Validate Sell 1.2.2 Prepare SX Transaction 1.2.3 Register Transaction Account Invalid Req. Advice Transaction Advice Sell Validation Trans. Confirmation Sell Details Account Update Sell Advice No. of Stock owned Account Sell Market Stock Price Sell Stock; Level 3 Transformational Modeling

39. - 38 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Data Flow diagrams may depict a situation at multiple levels of granularity. By that we mean a process in a data flow diagram may be decomposed into an entire new dataflow diagram at a lower level, and so on. At each lower level, there will be more detail of the model visible. Conversely, one can say that a higher level process can be described in terms of a dataflow diagram composed of simpler, lower level processes, data flows and data-stores. However this decomposition process must stop at some stage. At that stage we shall still have a dataflow diagram that only depicts the transformation of inputs to outputs of various processes. It however does not say HOW each leaf level process should achieve this. This may be obvious but is not defined. Transformational Modeling

40. - 39 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Dataflow diagrams are more so a mechanism for abstraction than a transformational modeling technique. They must be accompanied by a complementary mechanism that defines the leaf level transformations. Something like a flowchart of each leaf process, a pseudo-code, mathematical equation, truth table or formal definition is needed. Important Note: Transformational Modeling

41. - 40 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Pseudo-code: begin Read r,a; Declare x,y; if { (a) L.T. 0 a=(-1)*a; }; Set x to r*sin(a); Set y to r*cos(a); Write x; Write y; end Convert to Cartesian 1.5.6 r a x y Transformational Modeling

42. - 41 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Mathematical expression: Convert to Cartesian 1.5.6 r a x y Desc. For 1.5.6 Transformational Modeling

43. - 42 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Activity diagrams depict the processing aspects of the system. They are similar to flowcharts except: ACTIVITY DIAGRAMS Activity charts allow synchronization They are similar to dataflow diagrams except: Transition between activities is via conditions not data. Activity charts allow synchronization Transformational Modeling

44. - 43 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Order Processing Finance Receive Order Receive Supply Select Outstanding order item Assign Goods to Order Assign Item to Order Reorder Item Add Remainder to Stock Check Line Item Cancel Order Check order Authorize payment [failed] [succeeded] Dispatch Order [Stock assigned to all line items and payment authorized] *[for each line item on order] * [for each chosen order item] [in stock] [all outstanding order items filled] [notify supply] [out of stock] Stock Manager Transformational Modeling

45. - 44 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Structure TransformationCausality Objects Classes Relationships Inputs Outputs Transformations Events States Sequences ENCAPSULATION

46. - 45 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design UML has a an array of notations and diagrams for modeling in each of these three views. Structure Modeling Class notation, object notation, Associations, Links, Class diagrams, object diagrams,… Transformational Modeling Actors, Transformational relations, Use Case diagrams, Context Diagrams, Activity diagrams,Transformational definitions, …

47. - 46 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Causal (Dynamic) Modeling Events, Activities, Actions, Transitions, States, Sequence diagrams, Collaboration diagrams, Statechart diagrams, etc.… In the next session we shall start with structural modeling and introduce some important elements of the UML notation set.

48. - 47 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Structural Modeling: Answers the question WHAT? We need to concentrate on static relationships between objects (SNAPSHOT). So, we need to depict: ObjectsClasses Links Associations Class Diagram

49. - 48 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design CLASSES The implementation of a type A generator for instances A class is depicted as a solid-outlined rectangle with compartments: Must have a name compartment May have other compartments (up to 3 more)

50. - 49 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The other compartments may contain: Compartment 2: Attributes Compartment 3: Operations Compartment 4: Others (Business rules, exceptions, etc.) Name Compartment Attributes Compartment Operations Compartment Other Compartment Widget color: Color position:Coord=(0,0) move(from:Coord,to:Coord=(50,50)) get_color( ):Color draw( ) draw_all( ) color /= “white”

51. - 50 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Class name and the class name compartment: The name compartment must be present The name compartment contains the name of the class. Class names are centered, begin with a capital letter and are in boldface. Abstract class names are italicized.

52. - 51 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Attributes and the attribute compartment: May be omitted when drawing high level diagrams Are denoted as left justified plain lowercase text strings The name may be followed by a colon ( : ) followed by the type of the attribute Optionally we can set the initial value of the attribute. To do so, the type name is followed by ( = ) and then the value

53. - 52 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design May contain a visibility tag. A visibility tag could be: +Public # Protected -Private

54. - 53 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Operations and the operations compartment: May be omitted when drawing high level diagrams Are denoted as left justified plain lowercase text strings. Abstract operations are italicized May have parentheses containing a comma separated list of the parameters of the method that implements the operation. Optionally the parameter list may have indicators. These are:

55. - 54 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design inParameter is only passed in to the operation outParameter is only passed out (returned) inoutBoth (Default is “in”) May have a return list containing one or a comma separated list of more than one formal parameters following a colon after the parameter list. Multiple return parameters, if there, must have a name and a type separated by a colon.

56. - 55 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design An operation may have a class scope. Class operations are underlined. May contain a visibility tag. A visibility tag could be: +Public # Protected -Private

57. - 56 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Attribute - color:Color=red Operation: # credit_rating(in candidate:Customer=current, in agency: Agent=dandb) : rating : Integer, reason : Text Usually we do not bother with this level of detail unless we aim to generate code automatically

58. - 57 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design TEMPLATES AND GENERIC CLASSES PAIR T1,T2 first:T1 second:T2 set_first(in T1) set_second(in T2) out( ): STRING Pair > (Integer,Integer) OR

59. - 58 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design OBJECTS An element of a type set. An instance of a class. An object is depicted as a solid-outline rectangle with up to 3 compartments: The top compartment is the name compartment. May have other compartments (up to 2 more)

60. - 59 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The other compartments may contain: Compartment 2: Attribute values Compartment 3: Other Name Compartment Attributes Compartment Other Compartment doowak: Widget color=Red position=(10,45)

61. - 60 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Object name and the name compartment: The name compartment must be present The name compartment contains the name of the object; if a name exists. The name structure, if there, must be underlined. If the name is not there, or for “un-named” objects, the colon must remain. The name may be followed by a colon ( : ) followed by a comma separated list of class to which the object belongs.

62. - 61 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design :Widget color=Red position=(10,45) An un-known or un-named object : An object, any object

63. - 62 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Attribute values and the attribute values compartment: It is optional and may not be present. If present, it contains the names of the relevant attributes of the class of which this object is an instance and the values relating to that attribute. Only attribute names and values of interest should be shown.

64. - 63 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design RELATIONSHIPS There are three basic types of relationship between classes. These are: Inheritance Aggregation Association

65. - 64 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design INHERITANCE Parent Child 2Child 1 Discriminator …...

66. - 65 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Person FemaleMale gender Example:

67. - 66 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design AGGREGATION Two types in UML: Weak aggregation Composition Brain Person Department Professor Composition Weak aggregation

68. - 67 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design ASSOCIATIONS Association shows a named relationship between instances of a class and other instances of itself or between instances of two or more other classes. Class A Class B Role A:Class Role B:Class Name of Association Multiplicity

69. - 68 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Each association has two roles, each role is a direction on the association. These roles can be explicitly named on the association with a label. If not explicitly labeled, then the role name is the same as the target class and may be omitted. Order Person customer Is placed by

70. - 69 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design ABABABAB 1 1..* 0..1 * An A is always associated with exactly one B An A is always associated with one or more B An A is always associated with zero or one B An A is always associated with zero or more B AB n An A is always associated with exactly n B n..m An A is always associated with n to m B Where n is any integer number greater than 1 Where n,m are integer numbers and m>n AB

71. - 70 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design An association may have direction. When it does, the direction is shown with an arrow. AB In the above diagram, A, is called the source and B is the target. A bi-directional arrow indicates navigability in both directions. AB

72. - 71 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design An association with a “many” side may be ordered. Ordering is shown as a label on the target class. Screen Window * {ordered} Visible on

73. - 72 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design An association may be higher than binary. A Ternary Association Name Class A Class B Class C

74. - 73 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design reservation Person Flight Seat Example:

75. - 74 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Association Attributes Person Accesses File * * permission Association Attribute

76. - 75 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Employee sales rep 0..1* Corporate Customer Personal Customer Product contactName creditRating remind() bill(Real) creditCard# Customer name address rating():Integer 1 {if Order.customer.rating = 5 then Order.isPrepaid := True} * line item Order 1 * dateReceived: Date isPrepaid:Boolean number:String price:Money dispatch() close(Real) quantity:Integer price:Money isFilled: Boolean creditRating() >=4 Courtesy: Martin Fowler, with some changes by Houman Younessi Order Line

77. - 76 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Workshop 1

78. - 77 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Event State A relevant punctuation in time The arrival of a message A stimulus received by an object A relevant interval in time Response of an object to a message or event A response to a stimulus Events take no time States are held in time

79. - 78 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design coin is inserted(amount) flight leaves(airline,number) mouse_button_clicked(button, location) item_select_mode cruising edit_mode Event State Events carry information from an object to another (a message), objects receive that information and may change state

80. - 79 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Event State Events can be thought of as a feature call on the target object. States can be thought of as an abstraction of the attribute values of the target object between two relevant events.

81. - 80 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design SEQUENCE DIAGRAMS A sequence diagram captures the order of events and the direction of the messages passed. There are two forms of sequence diagrams: Simple sequence diagrams (Event Traces) Full sequence diagrams with concurrency

82. - 81 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design caller:Person callee:Person Modem1:Modem modem2:Modema_line:Connection wake connect sound_dial_tone acknowledge accept_dial_ sequence ringing_tone disconnect dial_tone dial sound_ring_tone connect stop_ring_tone disconnect_signal break_connect stop_ring connect picked_ up ring_phone routed receive_call_ signal dial_tone phone_ringing connected sound_dial_tone

83. - 82 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design modem1:Modem a_Line:Connection connect() sound_dial_tone() *[n]dial(n:Digit) modem2:Modem sound_ring_tone() ring_tone() picked_up() connect() [while caller not hang_up()] disconnect signal() break_connection() [while caller not hang_up()] *[n]dial(n:Digit)5 Asynch. Event Synch. Event Activation Continuation Condition Iteration Condition Object life termination routed() receive_call_signal() stop_ ringing_tone() stop_ ringing() break_connection() sound_dial_tone()

84. - 83 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design modem1:Modem a_Line:Connection connect() sound_dial_tone() *[n]dial(n:Digit) modem2:Modem sound_ring_tone() ring_tone() picked_up() connect() [while caller not hang_up()] disconnect signal() break_connection() routed() receive_call_signal() stop_ ringing_tone() stop_ ringing() break_connection() sound_dial_tone() caller:Person callee:Person wake acknowledge ringing_tone connected disconnect dial_tone phone_ringing connected dial_tone dial

85. - 84 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design modem1:Modem a_Line:Connection connect() sound_dial_tone() *[n]dial(n:Digit) modem2:Modem sound_ring_tone() ring_tone() picked_up() connect() [while caller not hang_up()] disconnect signal() break_connection() routed() receive_call_signal() stop_ ringing_tone() stop_ ringing() break_connection() sound_dial_tone() wake acknowledge ringing_tone connected disconnect dial_tone Phone_ringing connected dial_tone caller callee dial

86. - 85 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design COLLABORATION DIAGRAMS Collaboration diagrams also show the message exchange (collaboration) between several objects. They do so by depicting the message exchange between object icons through numbering the messages traveling between these objects.

87. - 86 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Modem:modem_2 Connection:aLine 1- connect() 3- *[n] dial(n:Digit) 10- disconnect_signal() 2- sound_dial_tone () 6a- ringing_tone() 8a- stops_ring_tone() 9a-connect( ) 11a- break_connection() 12a- sound_dial_tone 4- receive_call_signal() 6b- sound_ring_tone() 8b- stop_ringing() 9b- connect() 11b-break_connection() 12b- sound_dial_tone() 5- routed() 7-picked_up() Modem:modem_1 EXAMPLE COLLABORATION DIAGRAM

88. - 87 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design STATE DIAGRAMS A state diagram relates events and states. State diagrams may be drawn from the perspective of the whole system as a single object, or from the perspective of any single object at any level of granularity. State diagrams may show concurrency or may be nested Usually it is best to draw the state diagram of only one object in the system at a time

89. - 88 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design idle dial tone do/sound_dial_tone() connecting do/receive_call_signal() ringing do/sound_ring_tone() do/ring_phone() connected disconnect_signal() picked_up() dial() routed() connect() disconnected reset() State Diagram of a modem communication line, normal case, successful connection. connected do/stop_ring_tone() do/stop_ring() do/connect() do/break_connection() do/sound_dial_tone()

90. - 89 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design idle dial tone do/sound_dial_tone() connecting do/receive_call_signal() ringing do/sound_ring_tone() do/ring_phone() connected disconnect_signal() picked_up() dial() routed() connect() disconnected reset() connected do/stop_ring_tone() do/stop_ring() do/connect() do/break_connection() do/sound_dial_tone() time-out do/ beep() time_out() busy tone do/ slow_tone() busy_num() fast busy tone do/fast_tone() busy_trunk() message do/play() message-done() invalid_num() reset() State Diagram of a modem communication line, with normal, and a number of non-normal cases.

91. - 90 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design ringing do/sound_ring_tone ( ) idle connect do/connect ( ) acknowledge. do/acknowledge ( ) dial. do/dial( ) data ex. disconnecting do/disconnect_signal() wake() sound_dial_ tone() dial() stop_ringing() connect( ) disconnect() break_connection() sound_ringing_tone() sound_dial_tone()

92. - 91 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design trans. Ends modem_1 trans. modem_2 trans start EOT modem_2EOS modem 1EOS making change idle do/ dispense item do/give change ready item takenchange taken dispense modem_1 trans. modem_2 trans start EOT modem_2EOS modem 1EOS data exchange

93. - 92 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Transformations This is the third modeling view. It answers the question “how”. Depending on level of granularity there are many techniques. Including: High Level: Activity Diagrams Low Level: Pseudocode Flowcharts etc. Not part of UML

94. - 93 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Activity diagrams depict the processing aspects of the system. They are similar to flowcharts except: ACTIVITY DIAGRAMS Activity charts allow synchronization They are similar to dataflow diagrams except: Communication between activities is via messages carrying data not the data itself Activity charts allow synchronization

95. - 94 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Order Processing Finance Stock Manager Receive Order Receive Supply Select Outstanding order item Assign Goods to Order Assign Item to Order Reorder Item Add Remainder to Stock Check Line Item Cancel Order Check order Authorize payment [failed] [succeeded] Dispatch Order [Stock assigned to all line items and payment authorized] *[for each line item on order] * [for each chosen order item] [in stock] [all outstanding order items filled] [notify supply] [out of stock]

96. - 95 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design WORKSHOP 2

97. - 96 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A most important stage of the software process is that of the Specification process. The specification process entails all those activities that relate to the identification and documentation of users’ needs. In itself, the Specification process has several elements or sub-components. These are: Requirements elicitation Requirements capture Requirements analysis Production of a specification Usecases are central to this process.

98. - 97 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Requirements Elicitation There are many techniques of Requirements elicitation. The following are some example techniques: Interviewing Questionnaires Joint sessions Document and process study Prototyping We shall not study this phase in depth but shall later return to it briefly to describe approaches that are appropriate in a usecase setting

99. - 98 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Requirements Capture Once software requirements are elicited, they must be captured and documented in a clear, unambiguous and accessible way. This is called Requirements Capture or Requirements Documentation. There are several popular techniques available: Simple Narrative Enhanced narrative, including: Scenarios and Usecases Pictures, diagrams and cartoons Formal Language

100. - 99 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Requirements are captured for several reasons. Amongst these are to: Ensure that our understanding of what is to be done coincides with that of the customer, Have a basis for writing of contracts, Be able to convey to our design and implementation colleagues precisely what needs to be developed, Have a basis for evaluating whether we have completed the project successfully.

101. - 100 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Goal Orientation A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the form of: “A system to do/be/achieve X” Example: A system to generate birth certificates A system to generate reusable components A system to provide a uniform computing platform across government agencies All these may actually refer to the same application software!

102. - 101 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Each system name implies a single goal that defines a certain boundary and a specific set of interactions which in turn define the context of the system. If you cannot clearly name a system (identify a label that clearly indicates the goal to be attained), you are not yet ready to proceed with its analysis. The system goal (name) implies a set of interactions between “the system” and the outside world (outside entities or stakeholders) and a set of transformations within the system that together achieve the purpose or goal implied. The border transcended by these interactions is called the boundary.

103. - 102 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Stakeholders: Stakeholders in any system may belong to one of these three categories: Clients: Beneficiaries or victims of the goal, it having been achieved Actors: Those who operate the system Owners: Those with the power to abolish the system. To correctly comprehend or describe a system, as many of its stakeholders as possible must be identified and their interactions with the system noted.

104. - 103 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Whilst it is important to identify and consider the impact and interaction of each and every stakeholder/role player with the system and with each other to better understand the system, it is unnecessary to model each in detail. It is the system within the boundary that is to be defined and analyzed not what lies outside. It is therefore permissible to abstract outside entities (stakeholders) into one or a small number of abstract entities or concepts. IMPORTANT NOTE:

105. - 104 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design parent  child  keyboard  PC Hardware  modem  exchange  modem  PC Hardware  screen  child  parent User  exchange  User UI  exchange  UI Modem  exchange  Modem Consider the case of “getting off-line”. These abstractions (of stakeholders) that play the role of outside entities interacting with the system are called Actors.

106. - 105 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Transformations: Transformations are a set of end-to-end activities that may be initiated by an interaction (a call) from the outside world but take place within the system in order to achieve the goal for which the system exists or is to be constructed. A set of transformations in a particular order describe how the system goal is achieved. A transformation can be (often is) in itself considered the goal for a subsystem of the system at a lower level.

107. - 106 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Scenarios: We stated earlier that transformations are end-to-end activities that show how a system goal is achieved or is to be achieved. It stands to reason therefore to accept that capturing these end to end activities in the order that they take place determines how a system works. We can do this simply by creating artifacts called Scenarios A scenario is the ordered end-to-end listing of activities that takes place between a system and its actors in order to achieve a goal.

108. - 107 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Constructing a scenario: In order to construct a scenario, we first need to identify and express the goal for the system of which the scenario would describe the transformations. This can be in the form of a system name. Having identified the goal, the main action implied by the system name would become the name or the focus of the scenario. We then identify and name all the stakeholders of the system that are significant in achieving the goal at hand. Each stakeholder would lead us to specific activities that may not have been foreseen. For example by identifying a system administrator, we may become aware of the need for system administration activities.

109. - 108 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design We then capture the end to end activities that would achieve the goal and the order in which they need to be performed, if an order is extant or implied. Otherwise we decide on the order. This is a crucial step as sometimes an order is not apparent but is extant. We then identify the initiating stakeholder that starts the scenario, and write down the first line of the scenario in the form of: Stakeholder action verb Example: customer places order or preferably Stakeholder action verb system or system component Example: customer selects place order

110. - 109 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The following lines take largely the same format but do not need to necessarily start with a stakeholder. Important A scenario describes an end-to-end set of actions that achieves a goal. No conditional should be present in a given scenario. Scenarios that assume this end-to-end action is completed successfully, are called primary scenarios. Scenarios that assume otherwise are called alternate scenarios.

111. - 110 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: A scenario for establishing a modem connection 1.Identify and express the goal, state system name: A system to establish a modem connection between two modems. It assumes that there are two modems, each on one side, connected to computing equipment (in this case two personal computers) and that the personal computers are ready and modems are installed and enabled properly and that the communication line is available (subscription exists).

112. - 111 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design 2.In this exchange John and Mary are the two individuals involved who wish to establish a connection using their modems. John initiates the call. 3. John sends “wake” signal to modem 1 Modem 1 connects to line Dial tone begins Modem sends Acknowledge to John John sends number sequence 555-1212 Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials 5 Modem 1dials 5 Modem 1 dials 1 ::::::: Mary’s modem receives call signal Call is routed Ringing tone is heard by John Modem 2 connects to line Modem 2 stops ringing Modems are connected Modem 1 sends data stream Modem 2 sends reply data stream John sends disconnect signal Modem 1 sends disconnect signal Line disconnects John is notified of disconnection Mary is notified of disconnection

113. - 112 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: Alternate scenario John sends “wake” signal to modem 1 Modem 1 connects to line Dial tone begins Modem sends Acknowledge to John John sends number sequence 5%5-1212 Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials % Modem 1dials 5 Modem 1 dials 1 ::::::: Recording indicates invalid number John disconnects

114. - 113 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design WORKSHOP 3

115. - 114 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Our example scenario indicated what actually happened between the stakeholders through a system. It says nothing about what specifically was asked of the system and what did the system specifically do or asked to be done. Our example scenario was between John and Mary, does it matter if it is between these two or between Gunter and Gretchen? Our example scenario had 28 lines. How many lines should there be in a scenario? Is there a minimum? A maximum? Does it matter? This is where usecases come in

116. - 115 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Scenarios Vs Usecases Scenarios are tools of requirements elicitation They are a tool by which we determine as many of the end-to-end activities that are to be part of our system and their alternates. Scenarios are concrete They are depictions of the actual activity between actual stakeholders and stakeholders and the system Scenarios are informal They have a casual format and arbitrary length

117. - 116 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Scenarios Vs Usecases Usecases are tools of requirements analysis and specification They are a tool by which we analyze system interactions and what interactions are required and in what order and hierarchy for the goal to be achieved. Usecases are abstract They are depictions of the abstract (except for leaf level usecases) activities between an abstraction of the stakeholders and the system or its components, in terms of lower level transformations. Usecases are formal They have a precise format and specific length.

118. - 117 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Back to systems theory A system is described in terms of its goal, which implies a boundary, which in turn implies (by exclusion) stakeholders who are outside the system scope but interact with it. As the artifact to be designed is “the system” and not its stakeholders, it is a good idea to concentrate on the system and its interactions with the outside world, which can be conveniently abstracted. There are two levels of interactional abstraction: Abstraction by elimination of intermediate elements Abstraction by categorization

119. - 118 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Each system name implies a single goal that defines a certain boundary and a specific set of interactions which in turn define the context of the system. If you cannot clearly name a system (identify a label that clearly indicates the goal to be attained), you are not yet ready to proceed with its analysis. The system goal (name) implies a set of interactions between “the system” and the outside world (outside entities or stakeholders) and a sequence of transformations within the system that achieves the purpose or goal implied. The border transcended by these interactions is called the boundary.

120. - 119 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Stakeholders: Stakeholders in any system may belong to one of these three categories: Clients: Beneficiaries or victims of the goal, it having been achieved Actors: Those who operate the system Owners: Those with the power to abolish the system. To correctly comprehend or describe a system, as many of its stakeholders as possible must be identified and their interactions with the system noted.

121. - 120 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Whilst it is important to identify and consider the impact and interaction of each and every stakeholder/role player with the system and with each other to better understand the system, it is unnecessary to model each in detail. It is the system within the boundary that is to be defined and analyzed not what lies outside. It is therefore permissible to abstract outside entities (stakeholders) into one or a small number of abstract entities or concepts. IMPORTANT NOTE:

122. - 121 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design parent  child  keyboard  PC Hardware  modem  exchange  modem  PC Hardware  screen  child  parent User  exchange  User UI  exchange  UI Modem  exchange  Modem Consider the case of “getting off-line”. These abstractions (of stakeholders) that play the role of outside entities interacting with the system are called Actors.

123. - 122 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Transformations: A Transformations is an element of a sequence of end-to-end activities that may be initiated by an interaction (a call) from the outside world but take place within the system in order to achieve the goal for which the system exists or is to be constructed. Therefore, a set of transformations in a particular order ( a sequence) describe how the system goal is achieved. A transformation can be (often is) in itself considered the goal for a subsystem of the system at a lower level.

124. - 123 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Scenarios: We stated earlier that transformations are end-to-end activities that show how a system goal is achieved or is to be achieved. It stands to reason therefore to accept that capturing these end to end activities in the order that they take place determines how a system works. We can do this simply by creating artifacts called Scenarios A scenario is the ordered end-to-end listing of activities that takes place between a system and its actors in order to achieve a goal.

125. - 124 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Constructing a scenario: In order to construct a scenario, we first need to identify and express the goal for the system of which the scenario would describe the transformations. This can be in the form of a system name. Having identified the goal, the main action implied by the system name would become the name or the focus of the scenario. We then identify and name all the stakeholders of the system that are significant in achieving the goal at hand. Each stakeholder would lead us to specific activities that may not have been foreseen. For example by identifying a system administrator, we may become aware of the need for system administration activities.

126. - 125 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design We then capture the end to end activities that would achieve the goal and the order in which they need to be performed, if an order is extant or implied. Otherwise scenarios must be found that imply the sequence we seek. We then identify the initiating stakeholder that starts the scenario, and write down the first line of the scenario in the form of: Stakeholder action verb Example: customer places order or preferably Stakeholder action verb system or system component Example: customer selects place order

127. - 126 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The following lines take largely the same format but do not need to necessarily start with a stakeholder. Important A scenario describes an end-to-end set of actions that achieves a goal. No conditional should be present in a given scenario. Scenarios that assume this end-to-end action is completed successfully, are called primary scenarios. Scenarios that assume otherwise are called alternate scenarios.

128. - 127 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: A scenario for establishing a modem connection 1.Identify and express the goal, state system name: A system to establish a modem connection between two modems. It assumes that there are two modems, each on one side, connected to computing equipment (in this case two personal computers) and that the personal computers are ready and modems are installed and enabled properly and that the communication line is available (subscription exists).

129. - 128 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design 2.In this exchange John and Mary are the two individuals involved who wish to establish a connection using their modems. John initiates the call. 3. John sends “wake” signal to modem 1 Modem 1 connects to line Dial tone begins Modem sends Acknowledge to John John sends number sequence 555-1212 Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials 5 Modem 1dials 5 Modem 1 dials 1 ::::::: Mary’s modem receives call signal Call is routed Ringing tone is heard by John Modem 2 connects to line Modem 2 stops ringing Modems are connected Modem 1 sends data stream Modem 2 sends reply data stream John sends disconnect signal Modem 1 sends disconnect signal Line disconnects John is notified of disconnection Mary is notified of disconnection

130. - 129 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: Alternate scenario John sends “wake” signal to modem 1 Modem 1 connects to line Dial tone begins Modem sends Acknowledge to John John sends number sequence 5%5-1212 Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials % Modem 1dials 5 Modem 1 dials 1 ::::::: Recording indicates invalid number John disconnects

131. - 130 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Our example scenario indicated what actually happened between the stakeholders through a system. It says nothing about what specifically was asked of the system and what did the system specifically did or asked to be done. Our example scenario was between John and Mary, does it matter if it is between these two or between Gunter and Gretchen? Our example scenario had 28 lines. How many lines should there be in a scenario? Is there a minimum? A maximum? Does it matter? This is where usecases come in

132. - 131 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Scenarios Vs Usecases Scenarios are tools of requirements elicitation They are a tool by which we determine as many of the end-to-end activities that are to be part of our system and their alternates. Scenarios are concrete They are depictions of the actual activity between actual stakeholders and stakeholders and the system Scenarios are informal They have a casual format and arbitrary length

133. - 132 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Usecases are tools of requirements analysis and specification They are a tool by which we analyze system interactions and what interactions are required and in what order and hierarchy for the goal to be achieved. Usecases are abstract They are depictions of the abstract (except for leaf level usecases) activities between an abstraction of the stakeholders and the system or its components, in terms of lower level transformations. Usecases are formal They have a precise format and specific length.

134. - 133 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A system is described in terms of its goal, which implies a boundary, which in turn implies (by exclusion) stakeholders who are outside the system scope but interact with it. As the artifact to be designed is “the system” and not its stakeholders, it is a good idea to concentrate on the system and its interactions with the outside world, which can be conveniently abstracted. There are two levels of interactional abstraction: Abstraction by elimination of intermediate elements Abstraction by categorization

135. - 134 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Abstraction by elimination of intermediate elements We have demonstrated this before: parent  child  keyboard  PC Hardware  modem  exchange  modem  PC Hardware  screen  child  parent modem  exchange  modem or child  exchange  child or any other set of two stakeholders Consider the case of “getting off-line”.

136. - 135 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design It is best to consider the inner-most or the outer-most set and eliminate the rest. This is of course only permissible when the elements in the chain have no direct connection with the system except through their downstream element.

137. - 136 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Abstraction by categorization In the case of John and Mary, John was the Caller, Mary was the Callee. Can we generalize the case by considering this more abstract case? When does the abstraction end? A category is usually a sub- category of another? When do we stop? Caller and Callee  User, User  Person, etc. It is customary to be as general as possible without loss of meaning.

138. - 137 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Behavioral Interaction: In addition to interactional abstraction (between stakeholders and systems) we can also have behavioral abstraction (within the system). Behavioral abstraction is the activity of describing the system through a set of abstract behaviors, themselves being described by other sets of behaviors. Behavioral abstraction allows us to concentrate on what is of import at any one time. It helps our brains to understand the situation more clearly and completely without being overwhelmed.

139. - 138 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The Miller Number: There is an assertion in psychology that the human brain can best deal with 7±2 chunks of information at any one time or level. Anything below 5 and you are wasting a level as it is not adding adequate detail, Anything above 9 and there is too much detail. We strive – in composing usecases – to work within the Miller limits. Each usecase should have 7±2 lines of transformation.

140. - 139 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Transformations: A transformation is a concise abstraction of a behavior. A transformation is also a mapping. It can be depicted as an end-to- end un-conditional path through a set of activities that achieves a certain end. A transformation is formally described in terms of its: Pre-conditions Invariants Variant/Transformation Post-conditions A usecase transformation should be no different.

141. - 140 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Pre-conditions: A transformation cannot commence unless all conditions necessary for it to commence have been already successfully conducted. For example a transformation (withdraw money form check account), cannot commence unless there is an account already opened (open_account( ) has succeeded), and there is a cash balance in the positive and equal or exceeding the amount to be withdrawn or there is an overdraft provision, etc. It is important to recognize that every transformation is a potential usecase and every usecase a transformation. So: Each usecase and each transformation within a usecase has a set of pre-conditions that must be satisfied.

142. - 141 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Invariants: Each transformation implies a set of activities that have to take place in exactly the same way, every time. This implies that in a given usecase described by a set of transformations, all transformations must always be applied and in exactly the same fashion: no conditionals are allowed. Conditionals imply other cases (similar to alternate scenarios) that we deal with separately.

143. - 142 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Post-conditions: Each transformation must when presented its pre-conditions, satisfy the goal for which it exists. Invariants imply that this goal should be unique and its accomplishment or otherwise clearly identifiable. However, this does not imply that each transformation only has a single post-condition as in addition to what must change, there are numerous conditions that must-not. Post-conditions must also ensure that what must not change, has not changed. For practical purposes, we only consider the positive post- conditions for usecases.

144. - 143 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Transformation format: A transformation must be formally defined. It must clearly indicate its source, its target and the action to be performed. Therefore a transformation must always be defined as below: Object A requests service S from Object B Example: UI requests service fetch(id) from Record Where UI happens to be the User Interface Object (an external Actor) and Record is an internal object to the system that has capability fetch( ) that requires parameter id.

145. - 144 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Sequence of transformations and usecase BSG (Base Structural Grammar) Rule of initiation: A usecase at any one level must start with an external object (external to the system scope), or an object representing an external object. That is, the first (left-hand side) object on the first line of a usecase must be an external object to that usecase. UI requests service fetch(id) from Record UI is an external object.

146. - 145 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Very important note: An object that is external to one context may be deemed internal to another even within a single usecase. This makes sense as each transformation line of a usecase is to be deemed as a system of an object (on the left-hand side) requesting a service from another object (on the right-hand side) which at the time is deemed to be THE system. On the following line the order of request is usually reversed, that is the object that was on the right-hand side is now the left-hand side (requester) object on the succeeding line. See next rule; rule of progression 1.

147. - 146 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design UI requests service fetch(id) from Record Record requests service Ack_valid( ) from UI On the first line UI is the external object and the Record or the system that contains Record is the system of concern (Record is the internal object), On the second line Record is the external object requesting a service from a UI system. In other words, if we were to design a Records system, fetch(id) would be a part of it but Ack_valid( ) is not. When designing a UI system, the ability to acknowledge if a record displayed is valid (Ack-valid ( ) ) is part of the system.

148. - 147 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of progression 1: The right-hand side object on the first line of a usecase must be an internal object (the “system” object or an object that is a component of the system) in our present context. UI requests service fetch(id) from Record Record is a component of the system being designed.

149. - 148 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of progression 2: Given a non-simultaneous (single-thread) situation, if the right-hand side object on line n is an internal object, the left- hand side object on line n+1 must be the same object UI requests service fetch(id) from Record Record requests service Ack_valid( ) from UI

150. - 149 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of progression 3: Given a simultaneous (multi-thread) situation, if the right-hand side object on line n is an internal object, the left-hand side objects on the relevant multiple succeeding lines (each signifying a thread) must be the same object. UI requests service fetch(id) from Record Record requests service validate( ) from UI Record requests service lock(id) from Database-manager

151. - 150 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of progression 4: Given a simultaneous (multi-thread) situation, each thread must follow rule of progression 2. If an order is implied in the threads, the order must be followed in an interleaved fashion. Object A requests service S( ) from Object B Object B requests service T1( ) from Object A Object B requests service T2( ) from Object C Object A requests service T11( ) from Object D Object C requests service T12( ) from Object E

152. - 151 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of progression 5: If the right-hand side object of a usecase line is an external object (actor), then the left-hand side object of the next line on that thread must also be an external object (not necessarily the same object). Object A requests service S( ) from Object B Object B requests service T( ) from Object A Object D requests service M( ) from Object E Objects in red are external objects

153. - 152 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of termination 1: Any thread may cease upon task completion. The last thread(s) may only terminate when the goal is met. Object A requests service S( ) from Object B Object A requests service R( ) from Object C Object B requests service P( ) from Object D terminated Object C requests service M( ) from Object E terminated Object C requests service N( ) from Object A Object A requests service …………………….

154. - 153 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Rule of termination 2: All threads must terminate, preferably on an external. That is the right-hand side object of any terminating thread (last line of a thread) should be (but does not have to be) an external object. Object A requests service S( ) from Object B Object A requests service R( ) from Object C Object B requests service P( ) from Object D terminated Object C requests service M( ) from Object E terminated Object C requests service N( ) from Object A Object A requests service ……………………. Object X requests service W( ) from Object F terminated

155. - 154 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Use Case: Communicate via Modem Actors: Caller, Callee Initiating Actor: Caller Events: Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from callee Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Cont’d next column Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Connected from Caller Modem 2 req. ser. Connected from Callee Caller req. ser. Disconnect from Modem 1 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 Modem 1 req. ser. Dial_tone from Caller Modem 2 req. ser. Dial_tone from Callee Example, incomplete

156. - 155 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Structural format of a usecase There are rules for writing usecase transformations, there is also a structure for keeping the important elements of a usecase together. There are many of these structural formats. Here we show two: A minimal one that represents the necessary minimum requirements A formal one that is comprehensive, detailed and in accordance to systems theory requirements.

157. - 156 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A minimum format requirement: Usecase name: Usually the name of the system or sub-system the goal of which is the reason why the usecase exists. Actors: A list of external objects that exchanges messages with the system Initiating actor: The external entity that starts the usecase (the object on the left-hand side of the first line of transformation sequence Transformations: The sequence of events that need to take place for the goal to be achieved.

158. - 157 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A Formal Template: Usecase name: Usually the name of the system or sub-system the goal of which is the reason why the usecase exists. Actors: A list of external objects that exchanges messages with the system Initiating actor: The external entity that starts the usecase (the object on the left-hand side of the first line of transformation sequence Type: Normal course or non-normal course (to be discussed later) Priority: How important is this usecase (discussed later)

159. - 158 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A Formal Template: Pre-conditions: A set of conditions that must be true before the usecase can be initiated and the name of the usecase or usecases that operationalize them. Transformations:List of end-to-end events that need to take place for the goal to be achieved. Post-conditions: Given the pre-conditions, a set of conditions that must exist when the usecase ends. Extension points: A list of points in the usecase where non- normal courses extend out.

160. - 159 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Subordinates: List of usecases that are subordinate to the present usecase, that is, usecases that expend an individual transformation of this usecase. Architectural Other – non-functional – requirements that Requirements:might impact the usecase Status: Where in the project are we with this usecase Features in:The list of usecase diagrams – if any – in which this usecase is depicted Sequence diagram:The name or address of the document that contains the sequence diagram relating to this usecase

161. - 160 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Separation of concerns: One of the central principles of software engineering is the idea of separation of concerns. Simply put, it states that: If at all possible deal with different concerns, separately. This implies that different use courses should be captured and dealt with separately. There are two types of usecase courses: Normal Course: The course of action for which the system exists or persists; the “solution” we want of the system. Non-normal Course: A capability the system should possess but was not created for that purpose.

162. - 161 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: A vending machine is there to dispense food, drink or cancer in exchange for an exact price. The “normal course” usecase for a vending machine is therefore the one dealing with receiving the exact change and dispensing the item selected. A non-normal course would be when the system asks for more money, not enough having been inserted in the first place, or making and giving change.

163. - 162 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Identifying non-normal courses: The process of identifying non-normal courses is very simple. Begin with the normal course which has been identified and its pre-conditions and transformations have been enumerated. Start with the pre-conditions. For each pre-condition ask if an alternate valid course would be possible if this pre-condition was not met. If so, name and develop it into a usecase. Then proceed to the transformations section. Start with the first line. Ask if there could be any other way to proceed at that line, than the one suggested by the normal course. Each one is a potential non-normal usecase.

164. - 163 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Combinatorial explosion: Beware of the menace of the combinatorial explosion. Theoretically, there can be an infinite number of possibilities (non- normal courses) for each line of transformation. In a solution bound to a Von Neumann machine the number of possibilities are however always finite. This is not necessarily good news. Ten trillion possibilities is still unmanageable. How do we battle this menace? We use the two concepts of abstraction and contextualization.

165. - 164 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Using abstraction to deal with combinatorial complexity: The method to employ is very similar to the method of equivalence partitioning in testing. In fact in a way it is the same method. The idea is to select not every possibility individually as a separate course but to select a sample case with the assumption that it can stand as the equivalent for an entire class of potential courses. For example we might consider one course of “more change needed” irrespective of whether the change needed is 3 cents or $1.05. No longer do we need to consider each individual needed change value. Of course this is a big assumption. Not all equivalences we assume are truly equivalent.

166. - 165 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Using contextualization to deal with combinatorial complexity: Given infinite time and resources, we can consider and implement every non-normal course. This is clearly impossible as for even a very simple system the time and resource requirements to do so would be astronomical. Like any other area of engineering, we therefore must compromise. The software engineer – may be in collaboration with the other stakeholders – should (must) decide on which non-normal courses to consider and which to ignore. A judgment must be made based on the impact the exclusion of a particular course might have on the system.

167. - 166 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Usecases and software quality characteristics: What would be the impact of excluding a normal course usecase or having an imperfect or incomplete one? What quality characteristic would suffer as a consequence? What would be the impact of excluding a non-normal course usecase or having an imperfect or incomplete one? What quality characteristic would suffer as a consequence?

168. - 167 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design One can therefore measure functionality and reliability of a system through the use of usecases. We shall not deal with this issue here in detail. Important note: Identifying a non-normal course and developing one are two different things. I may recognize that a vending machine may need to deal with foreign currency but not do anything about it.

169. - 168 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A transformation set, a usecase and a usecase folder: These terms are often confused, sometimes even by experts. A transformation set is the “transformation/behavior” section of a usecase. Admittedly, it is the most important part of a usecase but it is not THE usecase. A usecase is the transformation set PLUS the other sections as described in the previous pages A usecase folder is the set of all usecases that relate to each other at one level. For example a normal course and all its developed non-normal courses. Subordinate usecases have their own folders.

170. - 169 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Relating usecases: The foregoing implies that usecases have a variety of relationships. A usecase may be a component of another, A usecase may be a subordinate of another, or A usecase may be a non-normal course of another We shall deal with these cases one at a time.

171. - 170 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A usecase is a component of another: Often we find ourselves repeating the same sequence of activities over and over. If these activities define a concrete objective to be achieved, then they represent a bona fide usecase. We may develop this usecase once and use it several times in different – larger – contexts. In this sense this usecase is a component of the other. Note: An arbitrary set of steps may not be simply bunched together and named a usecase to then be used as a component. For a component usecase to be a component usecase, it first has to be a usecase and that means supporting a concrete goal.

172. - 171 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A usecase is a subordinate of another: Each usecase has a set of transformations; one per line. Each transformation in itself implies a goal – a subordinate goal – to be achieved. The usecase describing the achieving of this subordinate goal is a subordinate usecase to the one above it.

173. - 172 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Use Case: Communicate via Modem Actors: Caller, Callee Initiating Actor: Caller Events: Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from callee Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Cont’d next column Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Connected from Caller Modem 2 req. ser. Connected from Callee Caller req. ser. Disconnect from Modem 1 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 Modem 1 req. ser. Dial_tone from Caller Modem 2 req. ser. Dial_tone from Callee Remember this?

174. - 173 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Use Case: Communicate via Modem Actors: Caller, Callee Initiating Actor: Caller Events: Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from callee Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Cont’d next column Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Connected from Caller Modem 2 req. ser. Connected from Callee Caller req. ser. Disconnect from Modem 1 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 Modem 1 req. ser. Dial_tone from Caller Modem 2 req. ser. Dial_tone from Callee We can first abstract by elimination of intermediate elements.

175. - 174 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Use Case: Communicate via Modem Actors: Modem 1, Modem 2 Initiating Actor: Modem 1 Events: Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 We now add thread information

176. - 175 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Use Case: Communicate via Modem Actors: Modem 1, Modem 2 Initiating Actor: Modem 1 Events: 0 Modem 1 req. ser. Connect from Line 0 Line req. ser. Sound_ dial_ tone from Modem 1 0 Modem 1 req. ser. Dial from Line 0 Line req. ser. Receive_ call_ signal from Modem 2 0 Modem 2 req. ser. Routed from Line 00 Line req. ser. Sound_ring_tone from Modem 1T 01 Line req. ser. Ring_phone from Modem 2 01 Modem 2 req. ser. Picked_up from Line 011 Line req. ser. Stop_ring_tone from Modem 1 012 Line req. ser. Stop_ringing from Modem 2T 013 Line req. ser. Connect from Modem 1 014 Line req. ser. Connect from Modem 2 013 Modem 1 req. ser. Disconnect_signal from Line 013 Line req. ser. Break_connect from Modem 1 014 Line req. ser. Break_connect from Modem 2 013 Line req. ser. Sound_dial_tone from Modem 1T 014 Line req. ser. Sound_dial_tone from Modem 2T We can now apply abstraction of categorization. We recognize that a modem is a type of Telephony Terminus Device (TTD). Others such as a hand- set or a fax machine also exist. This would allow for devices other than a modem to be included.

177. - 176 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design We are still dealing with 17 lines of transformations, significantly larger than the 7±2 suggested by the Miller’s rule. Use Case: Communicate via Modem Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0 TTD1 req. ser. Connect from Line 0 Line req. ser. Sound_ dial_ tone from TTD 1 0 TTD1 req. ser. Dial from Line 0 Line req. ser. Receive_ call_ signal from TTD2 0 TTD2 req. ser. Routed from Line 00 Line req. ser. Sound_ring_tone from TTD1T 01 Line req. ser. Ring_phone from TTD2 01 TTD2 req. ser. Picked_up from Line 011 Line req. ser. Stop_ring_tone from TTD1T 012 Line req. ser. Stop_ringing from TTD2T 013 Line req. ser. Connect from TTD1 014 Line req. ser. Connect from TTD2 013 TTD1 req. ser. Disconnect_signal from Line 013 Line req. ser. Break_connect from TTD1 014 Line req. ser. Break_connect from TTD2 013 Line req. ser. Sound_dial_tone from TTD1T 014 Line req. ser. Sound_dial_tone from TTD2T

178. - 177 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2T Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT Use Case: Establish_call Actors: Call_register(CR), FSLX, NSLX Initiating Actor: Call_register Events: 0CR req. ser. Req_ring( ) from FSLX 1CR req. ser. Req_ring_tone( ) from NSLX 0FSLX req. ser. Ring( ) from TTD2 1NSLX req. ser. Sound_ring_tone( ) from TTD 1T 0TTD 2 req. ser. Picked_up( ) from CR 00CR req. ser. Req_stop_ring_tone( ) from NSLX 01CR req. ser. Req_stop_ring( ) from FSLX 00NSLX req. ser. Stop_ring_tone( ) from TTD 1T 01FSLX req. ser. Stop_ring( ) from TTD 2T NSLX: Near-side Local Exchange FSLX: Far-side Local Exchange

179. - 178 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A usecase is a non-normal case of another: This situation has been adequately discussed.

180. - 179 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Pre-conditions and pre-condition operationalization Usecases also have pre-conditions defined for them. Each usecase is in final analysis nothing but a transformation; and transformations have pre-conditions. But what is a pre-condition? A pre-condition is simply a transformation that has to have occurred before the current transformation (this usecase) can occur. If so, then each pre-condition, being a transformation, implies a usecase. So each precondition must be related or recognized as an existing usecase, or if none exists, then it has to be defined. This is called pre-condition operationalization. All pre-conditions must be operationalized.

181. - 180 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: Usecase place_order has a pre-condition user_is_logged_in. This implies that there has to be a usecase log_in somewhere in the system. Two possibilities exist: 1.There is a usecase at a higher level with a set of transformations that reads something like: ::::::::: 3. UI requests service log_in( ) from Guardian 4. Guardian……… :::::::::::: 7. UI requests service place_order(ord_details) from Shipment ::::::::::::

182. - 181 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: or: 2. This is the top level, in which case we either recognize a need for even a higher level or recognize the need for a usecase called log_in.

183. - 182 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Using usecases to extract an object-oriented models: Extracting the dynamic model A well-formed usecase can tell us which object requested what service from which other object and in what sequence. It also captures (although deficiently) whether there was simultaneity and parallel threads. This is almost all the information we need to extract an object- oriented dynamic model of the situation. This could be in the form of sequence diagrams, collaboration diagrams or later, state diagrams.

184. - 183 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Extracting sequence diagrams: If we have a well-formed usecase, construction of a sequence diagram becomes rather trivial. A sequence diagram depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. Usecases do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

185. - 184 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The left-hand side object of any one line of usecase is a client object, the right-hand side one the server for a particular message request, which is the transformation of that given line. Therefore all objects needed for the sequence diagram all simply the left- hand side and the right-hand side words of the transformation set. A message (an arrow in a sequence diagram) is from a client to a server, thus it is from the life-line of a left-hand side object to the one of the right-hand side. The label on it is the name of the transformation. The order of the arrows are the order of the lines. Use rules of progression to figure out multi-threading.

186. - 185 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design TTD1:TTD Exchange:Connection Attempt_conn( ) TTD2:TTD Attemp_disconn( ) Reset( ) Disconnect( ) Establish_call( ) Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2T

187. - 186 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design TTD1:TTD NSLX:LX Connect( ) Receive_call( ) Routed( ) Dial( ) Dial-Register:RegFSLX:LX Sound_dial_tone( ) Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

188. - 187 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Extracting collaboration diagrams: Collaboration diagrams contain the same essential information as sequence diagrams. A collaboration diagram also depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. As we know usecases also do exactly the same and well- formed ones contain all the necessary information to extract a sequence diagram.

189. - 188 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design TTD2:TTD Exchange:Connection 1- Attemp_connect( ) 3- Attempt_disconnect( ) 4a- Disconnect( ) 2- Establish_call ( ) 4b- Reset( ) TTD1:TTD Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2T

190. - 189 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design TTD1:TTD NSLX:LX 1. Connect( ) 3. Receive_call( ) 4. Routed( ) 2b. Dial( ) Dial-Register:Reg FSLX:LX 2a. Sound_dial_tone( ) Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

191. - 190 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A well-formed usecase can tell us which object requested what service from which other object. Therefore a full set of well-formed and related usecases would contain in it all the objects that exchange messages in the system and the messages that they exchange. As each object must belong to a class, all classes required in the system are therefore identifiable. As each message is a request for an object to perform an operation, all the operations are also known. The hierarchy of usecases and their subordinate ones also indicate a structural hierarchy. This almost all the information we need to extract an object- oriented static model. This could be in the form of a class diagram.

192. - 191 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Extracting a class diagram: Each object (right-hand side or left-hand side) must belong to a class. So each object named in a usecase implies a class. Each class has a number of operations that it has to perform. So the operations indicated by the usecase define the object as its class.

193. - 192 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Each line of usecase at level n implies a pair of objects (therefore also classes) and an operation on the server class. This latter class may be (usually is) a complex class (an entire system or sub- system) and the operation implied with respect to it a complex behavior. This latter operation may however be now taken as the subject for a new usecase, implying that the server object at level n is now our “system”, with (for the moment) one goal; the operation it has to perform. Now we can start the system analysis effort over again, this time at the lower n+1 level of granularity. This implies new lower level (component) objects (and therefore

194. - 193 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design classes which would logically compose the higher level object at level n. So there is a compositional relationship between the levels of a usecase and objects with which we aught to deal.

195. - 194 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Attempt_connect( ) Attempt_disconnect( ) Connection Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2T

196. - 195 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Dial( ) Dial_register Routed( ) Call_Register Connect( ) Receive_call( ) Local_exchange Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

197. - 196 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Dial( ) Dial_register Routed( ) Call_Register Connect( ) Receive_call( ) Local_exchange Attempt_connect( ) Attempt_disconnect( ) Connection a_Number

198. - 197 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Dial( ) Dial_register Routed( ) Call_register Connect( ) Receive_call( ) Local_exchange Attempt_connect( ) Attempt_disconnect( ) Connection Register a_Number

199. - 198 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Reviewing usecases: Like any other artifact in software engineering, usecases may also be reviewed. We review usecases from the perspective of: 1.Well-formedness 2.Completeness 3.Fit We shall discuss these one at a time.

200. - 199 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Well-formedness: A usecase is well-formed if it follows the one initiation, five progression and two termination rules. There may be other rules added to these to cater for architectural concerns, but that is of no concern to us here. Should extra rules exist, then following these is also a requirement of well-formedness. Additionally, to be well-formed, a usecase must be documented in one of the accepted usecase documentation formats. The one provided herein is recommended.

201. - 200 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Completeness: There are two aspects to completeness; Essential completeness, and Structural completeness We must ensure both.

202. - 201 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Essential completeness is ensured when there is covered traceability to at least the functional requirements set. This means that all stated and implied functional requirements must be covered by usecases. Structural completeness is ensured when all named transformations have been either expanded into lower level usecases or into procedural flow (if at leaf level). We also need to ensure that all necessary non-normal course usecases have been considered and documented. It is also necessary to ensure that there is a relevant entry in each cell of the usecase template and that those containing no entries are explicitly mentioned to be blank.

203. - 202 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Fit: Here we must ensure that everyone is happy with our usecase set. We must check for understandability, logical consistency, and necessity (that there is nothing we don’t need). You need to review with all stakeholders: Review with Clients Review with Actors, and Review with Owners. Remember that there are several systems with which you are concerned here, not just a software specification.

204. - 203 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A system to achieve goal X (the software specification) A system to develop system to do X A system to system administer the system that achieves X A system to deliver value for money A system to shine and stay employed or be promoted

205. - 204 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Who should be present at the review? Project chief architect Project manager Chief analyst – usecase developer(s) Project Owner or representative Chief developer/programmer End user representatives

206. - 205 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The Domain Relevance Test The Absorption Test The Attribute/Function Test KEEPING THE RIGHT CLASSES Applying these techniques shall identify many potential classes from the domain. We now need to sift through these and select a coherent set of the “right” classes, discarding the rest. To do so we apply a number of heuristics (Younessi et al.; 1995): The Domain Relevance Test The Absorption Test The Attribute/Function Test Enabling Review

207. - 206 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The Domain Relevance Test: Ask the following: Does the Provisional Class/Object relate to the purpose for which the system exists? Is information retained within the relevant system about this Class/Object? Does this PCO have a behavior that is needed by the system? Does this PCO have more than one attribute and/or behavior?

208. - 207 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The Absorption Test; First identify all PCOs that have identical or semantically close names. Investigate if these names actually refer to the same entity. This may not always be the case: Clerk  LoanClerk or TaxationClerk In such situations rename all for clarity. Investigate if different PCOs have the same name. Resolve.

209. - 208 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Attribute/Function Test: Isolate PCOs that have only one attribute or function. Isolate PCOs whose name is a quantity which is simply derived by computation. Absorb these PCOs into other PCOs that can logically contain them.

210. - 209 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design ATTRIBUTES An attribute is one aspect of reality relating to the class about which we need information. In fact an attribute is the shorthand for a question about the class. For example: name: Person This really means: What is the name of this person?

211. - 210 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design There are three general categories of attributes: Nominal attributes: They give the object a name e.g. person’s SSN Essential attributes or Intrinsic attributes: They describe some feature of the object, e.g. person’s DOB Referential attribute: They relate one object to another e.g. person’s job In essence attributes are how the object is identified. In order to find the relevant attributes, ask the following questions: How would anyone in this domain describe this class? How would anyone in this domain recognize this class? What questions would this class be responsible to answer in this domain?

212. - 211 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Good attributes should have the following characteristics: Relevant: An attribute must relate to the universe of discourse; e.g. color of check not relevant in a banking system Atomic: An attribute must contain one value at any one time Encompassing: An attribute must be characteristic of the entire object not a component of it; e.g. diameter is an attribute of a tire not of a car Local(non-relational): The attribute of an object must not attempt to capture a characteristic of a relationship; e.g. permission_value is an attribute of Permission not of either a Person or a File.

213. - 212 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design OPERATIONS Operations are things that a class does (for other classes). They are the responsibilities of the class. This must be contrasted with things that class a does for itself. These are the private methods. We are concerned with operations (i.e. responsibilities). Operations can also be simple or complex. Simple operations are not necessary in an analysis model. Simple operations include: Connect(), get(), set(),disconnect().

214. - 213 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Operations are found by looking for: Action verbs in a problem statement or use case Responsibilities on a CRC card Actions and activities of a state diagram (if available)

215. - 214 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Object orientation is all about message passing between objects. For messages to pass between objects (programming view): Object C:c passes object B:b as an argument in a message to object A:a. Object A:a contains object B:b. Object A:a has a link to object B:b Object A:a’s service belongs to object B:b ACCESS CONTAINMENT ASSOCIATION INHERITANCE In the analysis domain, these are all forms of relationships

216. - 215 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Technically speaking an association is a relationship between the classes of objects. This means that a link is established between these objects that are instances of this association. A link between two objects lets one object be mapped to the other. This is a static relationship between classes, it is NOT a path for a message or a dynamic link between two individual objects.

217. - 216 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Look for the following categories: A is a physical part of B e.g., Wing-Airplane A is a logical part of B e.g., FlightLeg - Flight A is physically contained in B e.g, Passenger, Aircraft A is logically contained in B e.g., Passenger-Manifest A is a description of B e.g. FlightPlan-Flight A is a line item of B (aggregand) e.g. OrderLine-Order A is a member of B e.g. Pilot-Airline A is owned by B e.g., Aircraft-Airline A has a contract with B e.g. Passenger-Airline A is an organizational subunit of B e.g. Tower-Airport A uses B e.g. Passenger-Flight

218. - 217 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Indicates a relationship of some permanence (or at least duration) between classes. The relationship is well defined, contextually meaningful and are usually an abstraction of a constant. Can be shown as: An association: A static mapping

219. - 218 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design AGGERGATION V. CONTAINMENT We said earlier that in UML, aggregation was modeled in two forms : Weak aggregation and Composition. What is important is to note that containment IS NOT a form of aggregation. (In fact there are seven forms of aggregation of which the above are only two examples but we shall not go into the details here).

220. - 219 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Containment is that relationship when an object is temporarily placed inside another. For example a picnic basket in the trunk of a car. In contrast aggregation is the relationship between objects which has a compositional, more permanent (not necessarily perpetual), and emergent properties. Containment is always transitive, aggregation may or may not be. Yet both containment and aggregation are always asymmetric.

221. - 220 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: An apple in a picnic basket in the trunk of a car (Containment) Left arm part of Houman, Houman part of CS department (Aggreg.) Now an apple, or a picnic basket although inside a car are not a part of the car in the sense that there is no emergent relationship or dependency between them. On the other hand, Houman’s arm is part of Houman and without it Houman will not be complete. Houman is also part of the CS department and without him (Houman hopes) the CS department is not complete.

222. - 221 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design This is the parent-child relationship. UML’s label for this type of relationship is GENERALIZATION. In fact there are three main forms of inheritance all of which may be gainfully used in object orientation but only one of these conforms to a generalization. The three types are: Generalization Specialization Restriction Inheritance

223. - 222 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The trouble stems from the confusion between the two concepts of sub-typing and sub-classing. Sub-typing is when A is-a B or more correctly A can-act-as-a B. Sub-classing (that is not sub-typing) is the relationship where A is-derived-from B but can not act as it. Sub-typing implies extension Sub-classing implies specialization or restriction

224. - 223 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design As the name implies sub-typing is a logical relationship between types. Specialization and restriction are physical relationships between implementations of classes. Example: MOUSE is a sub-type of MAMMAL A BINARY_SEARCH_TREE is a sub-type of BINARY_TREE For B to be a sub-type of A, it first has to be an A. Then it can only ADD features, leaving all other features unchanged.

225. - 224 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Specialization is the relationship between classes where one class is altered to yield another by changing one or several of its features. Example: Compound_Interest_Account v. Simple_Interest_Account Note: A C.I.A. is not or can not act as a S.I.A. but we can take a S.I.A and change its feature that calculates interest to obtain a C.I.A.

226. - 225 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Restriction is the relationship between classes where one or several features of one class is restricted (locked) to yield another. Example: Interest_Bearing_Account v. No_Interest_Account Note: A N.I.A. is not or can not act as an I.B.A. but we can take an I.B.A and lock its feature that calculates interest to obtain a N.IA.

227. - 226 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The major differences between ER Diagrams and Class Diagrams: ER Only models persistent data Class diagramsModel persistent AND transient objects ER The relationships are mappings Class diagramsThe relationships are mappings and other structural ER Depicts only attributes (static individual state no information about possible operations that interact with this state Class diagramsDepicts attributes AND operations

228. - 227 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The CRC technique is used either after use cases have been developed or whilst this is happening. It has essentially four uses: To extract a model. To identify model elements such as classes, methods and associations To validate or complete use cases To refine a model To validate a model and highlight model/design flaws CLASS-RESPONSIBILITY-COLLABORATION (CRC)

229. - 228 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design CRC CARDS The process of production of CRC cards is most aligned with the first utility mentioned: To identify model elements such as classes, methods and associations. A CRC card is a 4  6 or a 5  7 card one which there are three main compartments. These compartments are: Class Name Responsibility Collaboration

230. - 229 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Class Name Responsibility Collaboration We develop a CRC card for each new potential class.

231. - 230 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Example: Order Check if item in stock Determine price Check for valid payment Dispatch :::::::::::::::::::::::::::::::::::: Order Line Customer On the back of the card there is usually one or sometimes up to four compartments:

232. - 231 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Project Hierarchy Attributes Description and comments Back of a CRC Card The Attribute compartment is the most important and houses information regarding the attributes of the potential class. Project Hierarchy Attributes Description and comments order no date etc. Supply Logistics Cash order, Credit Order

233. - 232 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design USING CRC CARDS Identify a potential class. This may be done with the help of a usecase. Create a card for that class by first selecting a name and putting that name on the card. Now identify one responsibility for which you feel this class must exist. Record this in the responsibilities column Identify the potential object that requests this responsibility of the class identified. Record this in the collaboration column and in front of the responsibility concerned. Identify the specific pieces of information needed to identify this class, or the class needs to hold. Write them as attributes on the back of the card. If this potential class is in a hierarchy, depict the hierarchy. Include some notes and comments if needed and identify the project. Produce a similar card for any new potential class that was discovered.

234. - 233 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design CRC GAME Once you have a handful of inter-relating CRC cards that collectively describe the system or at least some of its functionality, you are ready to play the CRC game. The game is played in two different forms depending on whether the intent is to validate the model or to refine it. To refine the model, you have to have your CRC cards and one person to play the role of each class. To validate you have to have a reasonably complete set of cards, a reasonably comprehensive set of use cases, one person to play each class and one or several small bean bags, balls or similar objects.

235. - 234 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design MODEL REFINEMENT Give each person the card they are to play the role of. Start at a logical place with some class. Debate if it is needed or if it needs to change. Start a thread that can be initiated by invoking one of the responsibilities of that class. Identify the collaborator (target) class. Pass control to that class by calling the service you need of that class. If collaborator class does not exist, create it. Keep playing until every responsibility on every card has been either discharged or debated and discarded. Similarly for every attribute. Do not be afraid to combine classes, or split them as necessary, or indeed discard them. Add responsibilities as and when needed or delete them if not useful.

236. - 235 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design MODEL VALIDATION Give each person the card they are to play the role of. Also nominate a person to play each external actor. Start with your top ranking use case. Identify the actor who initiates things and give him or her the bean bag. The actor starts a thread that can be initiated by passing the bag to the correct class according to the use case. The class checks if it can accept the bag. If yes, it does so, if not we raise an alarm and debate and rectify the model. The class now passes the bag to a class whose service it needs (calls), a class for which it is a collaborator. Keep playing until the use case is complete and update the model if necessary Go to the next use case

237. - 236 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design DESIGN OPTIMIZATION When we design software, we must consider many important aspects if our solution is to be a good, even an acceptable one. Some of these concerns are: System architecture System topology Dealing with system (as opposed to software) concurrency Hardware software trade-offs Data store and data management Choosing software control implementation (procedure v. event v. concurrent models) Boundary conditions and many many more

238. - 237 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design These issues are common amongst virtually all systems to be designed and there is nothing particularly object oriented about them. As such we shall not cover these issues in this treatment. What we shall deal with is a set of design guidelines when dealing with object oriented software.

239. - 238 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design VISIBILITY Simple idea with many subtle complications UML provides three labels: Private (-), Protected (#) and Public (+). Unfortunately these three labels are either insufficient when mapped to the visibility scope of some OO languages (e.g. Eiffel), or confusing as sometimes the definitions have subtle differences depending on what the target language might be. I do not wish to go into language specifics but for example protected in C++ and in Java are slightly different. The private visibility in Smalltalk is more like the Java protected visibility than

240. - 239 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design The C++ or Java private visibility. Eiffel instead has an elaborate and highly effective visibility mechanism which UML does not even approximate. Java has a package visibility which is does not have a corresponding symbol in UML. CONFUSED? Study and FULLY understand the visibility rules of the target language and design accordingly. Invent new labels if you must.

241. - 240 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Redundant Associations During analysis we removed many redundant associations. During design we may want to put some back in. Consider the following: Company Person Skill * * What is the process to find all who have skills in marine engineering? Let us say there are 10,000 people in the company and there are approximately 10 skills registered against each employee.

242. - 241 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design If only 10 employees have this skill what is the hit ratio? 10000/1 Now consider the following design: Company Person Skill * * * Has engineering skill Now if this company is an engineering company, this scheme will not help much. But if this is a bank who wants to finance a marine park, then…. *

243. - 242 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design There is no free lunch Where is the cost? You have to create an index on engineering skills. Now if there are a 100 engineers what will be the hit ratio? 10/1 There is a UML notation for indices, it is called qualifiers Company Person * * * Has engineering skill Skill * Eng. Skill qualifier

244. - 243 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Derived Elements To gain efficiency it may be useful to derive and store attributes rather than calculate them every time. Person Name DOB Today’s date Person name DOB /age The slash mark ( / ) before the attribute name indicates that it is derived.

245. - 244 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design N-ary Associations They are a problem. In fact some modeling languages and processes (e.g. OPEN) do not support them. Although semantically it is always the case that an n-ary association would lose information when resolved into n- binary associations, practically, we have no choice. Identify ALL higher than binary associations and resolve them into as many binary associations as needed. Usually more than n.

246. - 245 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Seemingly contrary to the previous tip, it is a good design decision to promote link attributes to bona fide classes. This will create a higher than binary situation which then needs to be resolved through indexing or some other means. Resist the temptation to absorb the association attributes into one or the other associated class.

247. - 246 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design OBJECT REPRESENTATION Try to use aggregation rather than inclusion in the design of your classes. Example: Real:x1 Real:y1 Real:x2 Real:y2 Line Point:x Point:y Line Real:x Real:y Point P1 P2

248. - 247 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Refrain from Inheritance of implementation Is a STACK a LIST? Can we have the following? List add () remove() first () last() Stack push () pop() top() What’s the Problem?

249. - 248 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Stack push () pop() top() List add () remove() first () last() - internal:List A stack has a list but is not one

250. - 249 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Designing associations Question all one-to –one associations, they usually are not. Reduce one-to-many or many-to-many associations by the use of qualifiers whenever it makes sense. Decide on the direction of the associations. Design each one-way associations as pointers to the target object Design two-way associations as two separate one way associations when appropriate Design one-to-many associations an iterator set Design a many-to-many association either as an object, a database table or a lookup table.

251. - 250 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Genericity PAIR T1,T2 first:T1 second:T2 set_first(in T1) set_second(in T2) out: STRING Pair > (INTEGER,INTEGER) OR Remember this?

252. - 251 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Provided that your language of implementation even allows for genericity, designing generic classes are harder than they seem. Genericity is not simply writing the program with a given set of actual types and then swapping them for generic labels. Example: An ordered pair of integers. An ordered pair of integers made from a generic template, an ordered pair of (student,grade).

253. - 252 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Abstract classes Separate the what from the how. Abstract the contract and deliver against it. This allows for changing the underlying implementation without having to change the client code. Stack {abstract} push () pop() top() List {abstract} add () remove() first () last() Arrayed _list Singly_linked _list Doubly_linked _list

254. - 253 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design RELATIONAL DATABASE MAPPING It is possible to map the elements of a UML object oriented design model to a Relational Database Management System (RDBMS). We start by recognizing the individual elements of one such design. There will be: Classes Associations, and Inheritance To consider. We shall do so in the next few pages.

255. - 254 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Mapping Classes to Tables Basically, each class maps to one or more table. In cases of a weak one-to-one association both classes may be mapped into one. Example: Person person_name address Attrib._name Nulls? Domain person_ID N ID person_name N name address Y address CREATE TABLE Person ( person-ID ID not null, person-name char(30) not null address char(30) PRIMARY KEY (person-ID));

256. - 255 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Mapping Binary Associations to Tables Each many-to-many association maps to a distinct table Company company_name address Person person_name address * * Owns-stock Stock-details Attrib._name Nulls? Domain Company_ID N ID person_ID N ID No._shares Y Share CREATE TABLE Owns-stock ( Company-ID ID not null, person-ID ID not null, No-Shares Integer, PRIMARY KEY (person-ID, company-ID), FOREIGN KEY (Company-ID) REFERENCES Company, FOREIGN KEY (person-ID) REFERENCES Person;

257. - 256 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Each one-to-many association maps to a distinct table or may be buried as a foreign key in the table for the many class. Each one-to-one association maps to a distinct table or may be buried as a foreign table, usually the latter. A qualified association (indexed association) maps to a distinct table with at least three attributes: the primary key of each related class and the qualifier. Aggregation follows the same rules as enumerated associations.

258. - 257 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Public-Company Listing-code No-shares Private-Company Owner Reg.-No. Mapping Inheritance The super-class and each sub-class map to a separate table Company company_name address CREATE TABLE Company ( Company-ID ID not null, Company-Name char(30) not null, address char(30), Company_type char(10) not null, PRIMARY KEY (Company-ID)); CREATE TABLE Public-Company ( Company-ID ID not null, Listing-code char(8), No-shares Integer, PRIMARY KEY (Company-ID), FOREIGH KEY(Company-ID) REFERENCES Company);

259. - 258 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design In a large project, the design will consist of many classes and a myriad of associations and other artifacts. It can become too complex to handle, comprehend or even draw. This is when packaging things into modules would help. Rules on packaging Rule 1: Keep classes that relate to the same concern or functionality together. Rule 2: Keep interactions and dependencies (coupling) between packages at a minimum

260. - 259 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design For example in a financial system dealing with stock-brokerage you might have some classes that deal with share dealing; you might have another set that deal with back-office accounting; yet another group of classes may deal with the user interface. There may be a set of classes that deal with communication between various systems and finally some classes that are used as utilities. How would you package things in such a system?

261. - 260 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design One good way is to package all share dealing classes together in a sub-system. All Back office accounting classes form another sub-system. Then the two can go together to form a larger sub-system called DOMAIN. All GUI classes can go together in a subsystem called GUI, all communications classes into one called COMMS. Then the two together can form a larger subsystem called INTERFACE. The Utilities classes go together in a package called UTIL. Names are only suggestions.

262. - 261 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Fortunately UML has a notational set that allows pictorial depiction of packages. The basic element is called a PACKAGE. PACKAGES DOMAIN INTERFACE Share Dealing Back Office GUI COMMS UTIL.

263. - 262 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Usecases and project schedule/Work Breakdown Structure (WBS): We had mentioned earlier that a usecase may be prioritized. Once we have a priority value for each of our usecases, we can utilize this information to create a project schedule. The process is very simple, we rank the usecases according to their priority and their level, we then start with the highest priority/level usecase and work our way down until we run out of time or money. This is how it works:

264. - 263 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design 1.All usecases receive a priority number. A priority number is a weighted index based on : 1. Impact on software Architecture 2. Importance to business or system 3. Importance to the development (provides lots of insight) 4. Complexity 5. Risk if excluded We can then score each usecase on an ordinal scale (1-5) and then sum up the scores. Thus a usecase may have a maximum priority number of 25.

265. - 264 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design 2. Each usecase also has a level number. A level number corresponds with the level of the hierarchy of usecases and its subordinates. The top level usecase is at level 1, all its subordinates are at level 2, etc. 3.No non-normal course usecase may have a priority number higher than or equal to the normal course. Of course different non-normal course may have different priorities. 4a.Rank usecases in order of priority but with higher level usecases of the same priority first. OR 4b.Rank usecases in order of level numbers but with higher priority usecases of the same level first.

266. - 265 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Using usecases as a basis for V+V: Usecases may be utilized in validation and verification of systems. It is however imperative to recognize that usecases are essentially specification tools and NOT a means of requirements elicitation; that role is filled by scenarios. Usecases therefore are tools to validate design and not programs. Despite their popular utility as test script, they are inappropriate for that purpose. This does not mean however that we cannot extract test scripts from usecases with a little effort.

267. - 266 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Using usecases to validate design: A usecase may be the guiding document for conducting a Class- Responsibility-Collaboration (CRC) game. CRC can highlight design faults and deviations of the design from the intended specification. Using usecases to extract test-scripts: The essence here is to extract an end-to-end non-abstracted sequence of events that describes a purposeful interaction with the system. Thus a usecase could yield many test-scripts. Equivalence partitioning is the technique to be used here.

268. - 267 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design Equivalence Partitioning: This is where each input condition is partitioned into sets of valid and invalid classes called equivalence classes. These are in turn used to generate test cases by selecting representative values of valid and invalid elements from each class. In this approach one can reasonably assume but not be certain that a test of a representative value of each class is equivalent to a test of any other value. That is, if one test case in a class detects an error, all other test cases in the class would be expected to do the same. Conversely, if a test case did not detect an error, we would expect that no other test case in the class would find an error.