2. - 1 - © Houman Younessi 2010 MGMT 6170 - Advanced Systems Analysis and Design Convener: Houman Younessi 1-860-548-7880 youneh@rpi.edu Lecture 4 A dvanced S ystems A nalysis and D esign Fall 2010

3. - 2 - © Houman Younessi 2010 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,…

4. - 3 - © Houman Younessi 2010 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

5. - 4 - © Houman Younessi 2010 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

6. - 5 - © Houman Younessi 2010 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

7. - 6 - © Houman Younessi 2010 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

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

9. - 8 - © Houman Younessi 2010 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

10. - 9 - © Houman Younessi 2010 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

11. - 10 - © Houman Younessi 2010 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

12. - 11 - © Houman Younessi 2010 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

13. - 12 - © Houman Younessi 2010 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

14. - 13 - © Houman Younessi 2010 MGMT 6170 - Advanced Systems Analysis and Design p5 p1 p2 p3 p4 t1 t2 t3 Causal Modeling

15. - 14 - © Houman Younessi 2010 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

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

17. - 16 - © Houman Younessi 2010 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

18. - 17 - © Houman Younessi 2010 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

19. - 18 - © Houman Younessi 2010 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

20. - 19 - © Houman Younessi 2010 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

21. - 20 - © Houman Younessi 2010 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

22. - 21 - © Houman Younessi 2010 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

23. - 22 - © Houman Younessi 2010 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

24. - 23 - © Houman Younessi 2010 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

25. - 24 - © Houman Younessi 2010 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

26. - 25 - © Houman Younessi 2010 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

27. - 26 - © Houman Younessi 2010 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

28. - 27 - © Houman Younessi 2010 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

29. - 28 - © Houman Younessi 2010 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

30. - 29 - © Houman Younessi 2010 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

31. - 30 - © Houman Younessi 2010 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

32. - 31 - © Houman Younessi 2010 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

33. - 32 - © Houman Younessi 2010 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

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