Software Design: Transform Analysis

Transform Analysis

 Transform analysis is strategy of converting each piece of DFD (may be from level 2 or level 3, etc.) for all the identified transaction centers. Draw a DFD of a transaction type (usually done during analysis phase)

 ·        Find the central functions of the DFD

 ·        Convert the DFD into a first-cut structure chart

 ·        Refine the structure chart

 ·        Verify that the final structure chart meets the requirements of the original DFD Let us understand these steps through a payroll system example:

   Identifying the central transform

The central transform is the portion of DFD that contains the essential functions of the system and is independent of the particular implementation of the input and output. One way of identifying central transform (Page-Jones, 1988) is to identify the Centre of the DFD by pruning off its afferent and efferent branches. Afferent stream is traced from outside of the DFD to a flow point inside, just before the input is being transformed into some form of output (For example, a format or validation process only refines the input – does not transform it). Similarly, an efferent stream is a flow point from where output is formatted for better presentation. The processes between afferent and efferent stream represent the central transform (marked within dotted lines above). In the above example, P1 is an input process, and P6 & P7 are output processes. Central transform processes are P2, P3, P4 & P5 - which transform the given input into some form of output.

 

First-cut Structure Chart

 

To produce first-cut (first draft) structure chart, first we have to establish a boss module. A boss module can be one of the central transform processes. Ideally, such process has to be more of a coordinating process (encompassing the essence of transformation). In case we fail to find a boss module within, a dummy coordinating module is created

In the above illustration, we have a dummy boss module ―Produce Payroll‖ – which is named in a way that it indicates what the program is about. Having established the boss module, the afferent stream processes are moved to left most side of the next level of structure chart; the efferent stream process on the right most side and the central transform processes in the middle. Here, we moved a module to get valid timesheet (afferent process) to the left side (indicated in yellow). The two central transform processes are move in the middle (indicated in orange). By grouping the other two central transform processes with the respective efferent processes, we have created two modules (in blue) – essentially to print results, on the right side.The main advantage of hierarchical (functional) arrangement of module is that it leads to flexibility in the software. For instance, if ―Calculate Deduction‖ module is to select deduction rates from multiple rates, the module can be split into two in the next level – one to get the selection and another to calculate. Even after this change, the ―Calculate Deduction‖ module would return the same value.

·        Refine the Structure Chart

Expand the structure chart further by using the different levels of DFD. Factor down till you reach to modules that correspond to processes that access source / sink or data stores. Once this is ready, other features of the software like error handling, security, etc. has to be added. A module name should not be used for two different modules. If the same module is to be used in more than one place, it will be demoted down such that ―fan in‖ can be done from the higher levels. Ideally, the name should sum up the activities done by the module and its sub-ordinates.

 

·        Verify Structure Chart vis-à-vis with DFD

Because of the orientation towards the end-product, the software, the finer details of how data gets originated and stored (as appeared in DFD) is not explicit in Structure Chart. Hence DFD may still be needed along with Structure Chart to understand the data flow while creating low-level design.

·        check the list of properties for transform flow characteristics

·        be aware that this is a guideline only

            Step 2b:

 ·        find and mark the center of transformation in the DFD

 ·        locate the center of transformation

 ·        follow input-driven flows into the center until the data is in an internal format, correct and 

       complete ===> mark position

 ·        trace back output-driven flows to the center until the data is complete and ready for presentation, but not         yet in external format ===> mark position

 ·        connect all markings: center of transformation

 

 ·        add data (and control) flows

 ·        further decompose (factor) were necessary

 ·        user interface handling modules

 ·        error-handling modules

 ·        add initialization & termination modules

 ·        check quality of design:

 ·        cohesion

 ·        coupling

 ·        reconfirm mapping with DFD

Business Process Modeling Notation(BPMN

 

What is Business Process Modeling Notation

What are your requirements regarding BPMN diagrams?

What is BPMN?

Business Process Modeling Notation (BPMN) is a flow chart method that models the steps of a planned business process from end to end. A key to Business Process Management, it visually depicts a detailed sequence of business activities and information flows needed to complete a process.

Its purpose is to model ways to improve efficiency, account for new circumstances or gain competitive advantage. The method has been undergoing a standardization push in the past few years and is now often called by a slightly different name: Business Process Model and Notation, still using the BPMN acronym. It differs from Unified Modeling Language (UML) used in software design.

Very recent history

Business Process Modeling Notation was developed by the Business Process Management Initiative (BPMI) and has gone through a series of revisions. In 2005, that group merged with the Object Management Group (OMG), which took over the initiative. In 2011, OMG released BPMN 2.0 and changed the method’s name to Business Process Model and Notation. It created a more detailed standard for business process modeling, using a richer set of symbols and notations for Business Process Diagrams. Since 2014, BPMN has also been complemented by a decision flow chart method called the Decision Model and Notation standard, since BPMN doesn’t naturally lend itself to decision flows.

Purpose and benefits

At a high level, BPMN is targeted at participants and other stakeholders in a business process to gain understanding through an easy-to-understand visual representation of the steps. At a more involved level, it’s targeted at the people who will implement the process, giving sufficient detail to enable precise implementation. It provides a standard, common language for all stakeholders, whether technical or non-technical: business analysts, process participants, managers and technical developers, as well as external teams and consultants. Ideally, it bridges the gap between process intention and implementation by providing sufficient detail and clarity into the sequence of business activities.

The diagramming can be far easier to understand than narrative text would be. It allows for easier communication and collaboration to reach the goal of an efficient process that produces a high-quality result. It also helps with communication leading to XML (Extensible Markup Language) documents needed to execute various processes. One main XML standard is called BPEL or BEPEL4WS, standing for Business Process Execution Language for Web Services.

BPMN 2.0 diagram elements and symbols

BPMN depicts these four element types for business process diagrams:

1. Flow objects: events, activities, gateways
2. Connecting objects: sequence flow, message flow, association
3. Swimlanes: pool or lane
4. Artifacts: data object, group, annotation

These are the individual elements and how they are used to define a business process:

Events

A trigger that starts, modifies or completes a process. Event types include message, timer, error, compensation, signal, cancel, escalation, link and others. They are shown by circles containing other symbols based on event type. They are classified as either “throwing” or “catching,” depending on their function.

Activity

A particular activity or task performed by a person or system. It’s shown by a rectangle with rounded corners. They can become more detailed with sub-processes, loops, compensations and multiple instances.

Gateway

Decision point that can adjust the path based on conditions or events. They are shown as diamonds. They can be exclusive or inclusive, parallel, complex, or based on data or events.

 

Sequence flow

Shows the order of activities to be performed. It is shown as a straight line with an arrow. It might show a conditional flow, or a default flow.

Message flow

Depicts messages that flow across “pools,” or organization boundaries such as departments. It shouldn’t connect events or activities within a pool. It is represented by a dashed line with a circle at the start and an arrow at the end.

Association

Shown with a dotted line, it associates an artifact or text to an event, activity or gateway.

Pool and swimlane

A pool represents major participants in a process. A different pool may be in a different company or department but still involved in the process. Swimlanes within a pool show the activities and flow for a certain role or participant, defining who is accountable for what parts of the process.

Artifact

Additional information that developers add to bring a necessary level of detail to the diagram. There are three types of artifacts: data object, group or annotation. A data object shows what data is necessary for an activity. A group shows a logical grouping of activities but doesn’t change the diagram’s flow. An annotation provides further explanation to a part of the diagram.

Who does business process modeling?

Business Process Modeling can range from simple, hand-drawn diagrams to more involved ones with expandable elements to provide sufficient implementation detail. At its most sophisticated, BPMN is conducted by credentialed analysts. The Object Management Group (OMG) provides OCEB 2, which stands for OMG-Certified Expert in BPM 2.0. One track is business-oriented, and the other is technical. OMG intends for BPMN 2.0 to standardize business process modeling in the same way that Unified Modeling Language (UML) standardized software modeling.

BPMN requires a commitment of time and energy, but the payoff in understanding and improvement can be huge. Version 2.0 builds on previous versions by providing a richer standard set of symbols and notations, allowing more detail for those who need it.

The idea behind Business Process Management is to create a life cycle of continuous improvement. The steps are model, implement, execute, monitor and optimize. BPMN diagrams play a key role in that.

Sub-models within a BPMN diagram

The diagrams are used to communicate with diverse audiences, both non-technical and technical. Sub-models allow the diverse viewers to easily differentiate between sections of the diagram, finding what’s most applicable to them. The types of sub-models are:

• Private business processes. These are internal to a specific organization and don’t cross pools, or organizational boundaries.
• Abstract business processes. These occur between a private/internal process and another participant or process. The abstract process shows the outside world the sequence of messages needed to interact with the private process. It doesn’t show the private/internal process itself.
• Collaboration business processes. These show the interactions between two or more business entities.

Other diagram types

In BPMN 2, there are these other diagram types: conversation, choreography and collaboration.

• Choreography diagram: Shows interactions between two or more participants. It also may be expanded with sub-choreographies.
• Collaboration diagram: Shows interactions between two or more processes, using more than one pool. All combinations of pools, processes and choreography may be used in a collaboration diagram.
• Conversation diagram: In general, this is a simplified version of a collaboration diagram. It shows a group of related message exchanges in a business process. It may be expanded with sub-conversations.

Key tips for business process modeling

1. Clearly define the scope of the process with a beginning and end.
2. You might first map the current business process to highlight inefficiencies before modeling a better way with BPMN.
3. Aim for BPMN diagrams that fit on one page, even if the page is poster-sized, as some are.
4. Lay out sequence flows horizontally. Show associations and data flows vertically.
5. You can create different versions of the diagram for different stakeholders, depending on the level of detail needed for their role.
6. BPMN is not appropriate for modeling organizational structures, functional breakdowns, or data flow models. Although BPMN depicts some information flows in business processes, it’s not a Data Flow Diagram (DFD.)

   

Spiral model

What is Spiral model- advantages, disadvantages and when to use it?

The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

Diagram of Spiral model:

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral model:

• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

 When to use Spiral model:

• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

Agile Model Pros and Cons

What is Agile model – advantages, disadvantages and when to use it?

Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications. Extreme Programming (XP) is currently one of the most well-known agile development life cycle model.

Diagram of Agile model:

Advantages of Agile model:

§  Customer satisfaction by rapid, continuous delivery of useful software.

§  People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.

§  Working software is delivered frequently (weeks rather than months).

§  Face-to-face conversation is the best form of communication.

§  Close, daily cooperation between business people and developers.

§  Continuous attention to technical excellence and good design.

§  Regular adaptation to changing circumstances.

§  Even late changes in requirements are welcomed

Disadvantages of Agile model:

§  In case of some software deliverable, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

§  There is lack of emphasis on necessary designing and documentation.

§  The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

§  Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

When to use agile model:

§  When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.

§  To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it.

§  Unlike the waterfall model in agile model very limited planning is required to get started with the project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. Changes can be discussed and features can be newly effected or removed based on feedback. This effectively gives the customer the finished system they want or need.

§  Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.

Intro to Agile Modeling

An Introduction to Agile Modeling

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices> for modeling software that can be applied on a software development project in an effective and light-weight manner. As you see in Figure 1 AM is meant to be tailored into other, full-fledged methodologies such as XP or RUP, enabling you to develop a software process which truly meets your needs. In fact, this tailoring work has already been done for you in the form of the Disciplined Agile Delivery (DAD) process framework. 

- See more at: http://www.agilemodeling.com/essays/introductionToAM.htm#sthash.xzJr8hw5.dpuf

The values of AM, adopting and extending those of extreme Programming v1, are communication, simplicity, feedback, courage, and humility. The keys to modeling success are to have effective communication between all project stakeholders, to strive to develop the simplest solution possible that meets all of your needs, to obtain feedback regarding your efforts often and early, to have the courage to make and stick to your decisions, and to have the humility to admit that you may not know everything, that others have value to add to your project efforts.

AM is based on a collection of principles, such as the importance of assuming simplicity when you are modeling and embracing change as you are working because requirements will change over time. You should recognize that incremental change of your system over time enables agility and that you should strive to obtain rapid feedback on your work to ensure that it accurately reflects the needs of your project stakeholders. You should model with a purpose, if you don't know why you are working on something or you don't know what the audience of the model/document actually requires then you shouldn't be working on it. Furthermore, you need multiple models in your intellectual toolkit to be effective. A critical concept is that models are not necessarily documents, a realization that enables you travel light by discarding most of your models once they have fulfilled their purpose. Agile modelers believe that content is more important than representation, that there are many ways you can model the same concept yet still get it right. To be an effective modeler you need to recognize that open and honest communication is often the best policy to follow to ensure effective teamwork. Finally, a focus on quality work is important because nobody likes to produce sloppy work and that local adaptation of AM to meet the exact needs of your environment is important.

To model in an agile manner you will apply AM's practices as appropriate. Fundamental practices include creating several models in parallel, applying the right artifact(s) for the situation, and iterating to another artifact to continue moving forward at a steady pace. Modeling in small increments, and not attempting to create the magical "all-encompassing model" from your ivory tower, is also fundamental to your success as an agile modeler. Because models are only abstract representations of software, abstractions that may not be accurate, you should strive to prove it with code to show that your ideas actually work in practice and not just in theory Active stakeholder participation is critical to the success of your modeling efforts because your project stakeholders know what they want and can provide you with the feedback that you require. The principle of assume simplicity is a supported by the practices of creating simple content by focusing only on the aspects that you need to model and not attempting to creating a highly detailed model, depicting models simply via use of simple notations, and using the simplest tools to create your models. You travel light by single sourcing information, discarding temporary models and updating models only when it hurts. Communication is enabled by displaying models publicly, either on a wall or internal web site, through collective ownership of your project artifacts, through applying modeling standards, and by modeling with others. Your development efforts are greatly enhanced when you apply patterns gently. Because you often need to integrate with other systems, including legacy databases as well as web-based services, you will find that you need to formalize contract models with the owners of those systems. Read this article for a better understanding of how AM's practices fit together.

Figure 2. Agile Model Driven Development (AMDD).

I would argue that AM is an agile approach to modeling that at its core AM is simply a collection of practices that reflect the principles and values shared by many experienced software developers. With an Agile Model Driven Development (AMDD) (see Figure 2) approach you typically do just enough high-level modeling at the beginning of a project to understand the scope and potential architecture of the system, and then during development iterations you do modeling as part of your iteration planning activities and then take a just in time (JIT) model storming approach where you model for several minutes as a precursor to several hours of coding.