Software Design Process A Process is a set of related and (sequenced) tasks that transforms a set of input to a set of output. Inputs Outputs Design Process.

Similar presentations

Presentation on theme: "Software Design Process A Process is a set of related and (sequenced) tasks that transforms a set of input to a set of output. Inputs Outputs Design Process."— Presentation transcript:

1
Software Design Process A Process is a set of related and (sequenced) tasks that transforms a set of input to a set of output. Inputs Outputs Design Process requirements specifications design specifications sequence of tasks Is this diagram very clear? What does the rectangle, arrow, or the circle mean? What about the coloring and the lables?

3
UML’s Activity Diagram We use Activity Diagram to “model” the activities (sequence of tasks) in a system –main components (& its functionality) –relationship (interactions) among components Activities (eventually decomposed down to functional actions, which are “atomic” in nature) Activity Diagram also depicts the “Flow” of 1.Control 2.Data (information)

4
UML’s Activity Diagram Software Design Process itself may be depicted or “modeled” with UML’s Activity Graph Diagram since a Design Process is composed of: 1.Activities or Tasks Represented as action nodes (rounded rectangles) 2.Flow (of control & data) Represented as arrows Activity 1 Activity 2Activity 3 Activity 4 This Activity Diagram depicts a “virtual machine” behavior of the process where there are tokens which run through the edges. 1) An action node begins Its execution when the tokens from all its incoming edges arrive. (implied synchronization) 2) When an action node begins execution it consumes all these tokens. 3) After a task is completed, the task node sends a token out on each of its outgoing edges. Token in begin Node Token in End Node

5
UML’s Activity Diagram Software Design Process may be depicted with UML’s Activity Graph Diagram since a Design Process is composed of: 1.Activities or Tasks Represented as action nodes (rounded rectangles) 2.Flow (of control and data) Represented as arrows Read Req. Doc. analyze Requirements prioritize Requirements Review Requirements This Activity Diagram depicts a “virtual machine” behavior of the process where there are tokens which run through the edges. 1) An action node begins Its execution when the tokens from all its incoming edges arrive. (implied synchronization) 2) When an action node begins execution it consumes all these tokens. 3) After a task is completed, the task node sends a token out on each of its outgoing edges. Token in begin Node Token in End Node

6
Decision and Merge Nodes Besides the activity nodes and the edges, we need a mechanism to depict alternative flow based on some decision. 1.Decision node 2.Guard 3.Merge node Review Req. spec. Write Req. spec. Approve Req. Spec. Req. Spec. Review [non-concur] [concur] 1) a decision node has a single entry edge, but multiple edges leaving it 2) a guard labels the “condition” that controls the flow through the edge (path) 3) a merge node has multiple entering edges but one exit edge A) If a token is available on any of the merge entering edges, it is passed to the leaving node. B) If a token is available on the decision node’s entering edge, a decision is made and a token is passed to the edge with the guard that depicts the decision Why do we need merge node here ? Activity Symbol

7
Fork and Join in Control Flow (Explicit Synchronization) Read Req. Doc. analyze Requirements prioritize Requirements Review Requirements When a token is available on the incoming edge of a FORK Node (thick line), the token is duplicated and posted on all the outgoing edges of FORK When tokens are available on ALL the incoming edges of a JOIN Node (thick line), a token is placed on the outgoing edge Note : this is a bit like the Petri net Also: Read page 39 of your text on “flow final node”

9
Activity Parameters Review Req. spec. Write Req. spec. Approve Req. Spec. [non-concur] [concur] Spec. for review Written Spec. reviewed spec. concurred Spec. approved Spec. apprReqSpec reqNotes - A process consumes inputs and produces outputs. - The inputs and outputs of a process may be represented as “parameters” to and from the process. - These parameters, in form of data or object node, are placed on the boundary of the activity symbol Req. Spec. Review Process reqNotes: Docs apprReqSpec : Docs Note that we have listed the parameters at the upper left corner of the Activity Symbol What about the input & output of the process? Data name and data typeprocess name

10
When to Use Activity Diagram? May be used to depict the design (especially a description of a set of actions) at either –High level (architectural and intermediate model) or –Low level (pseudo code level) depicting: 1.Activity 2.Control flow 3.Data and data flow (See page 45 of your text) Also, note that an action node in an activity diagram may itself be expanded into an activity diagram giving us the capability of further refinement

11
Some Guideline to Activity Diagram Draw the flow control from left to right and from top to bottom. Name activity nodes with verb phrases. Name data nodes and data pins with noun phrases. Use the guard and labels on every output edge of a condition node. Use data flow, and not both control and data flow, whenever data flow alone can suffice. Make sure that all flows entering a node can provide tokens concurrently, so that no deadlock can occur or use merge nodes. Use Activity Diagram to “model” the dynamic (or flow) process. Noted: the condition node and the merge node syntax, diamond, being the same, is NOT appealing ---- room for improvement

16
Software Design Management Designing Software is an activity that resembles a project in itself. –Operations (regular recurring work payroll, monthly finance, etc.) –** Project (one time effort that starts and achieves specific goal) Design Activities needs to be managed as a project with: –Planning –Organizing –Staffing –Tracking (monitoring) –Leadership-ing (adjusting and redirecting) Management of any project is very “iterative” between tracking and leading. But the process may also feedback to planning and re-adjust the plan

17
Managing Design Work Managing any project depends a lot on how the work is decomposed – Design may be viewed as: –Product Design Product Design Analysis: –Understanding the overall customer problem –Understanding the details of customers’ needs and wants Product Design Resolution: –Reviewing, clarifying and prioritizing the overall problems and details –Defining, documenting,& agreeing on the problem and details in SRS document –Engineering Design Engineering Design Analysis: –Study and analyze the SRS Engineering Architectural Resolution: –Generating and documenting a high level architectural design document Engineering Detailed Design Resolution: –Generating and documenting a detailed designed document Management Activities with this view of Design - WBS: –Planning the following: Estimating of time needed Estimating resources needed Putting together a schedule Assessing risks –Organizing the project Team structure Authority structure –Tracking (monitoring) Schedule Design outputs-quality –Leading (adjusting) Providing direction & support This is the Work Breakdown Structure (WBS)