Saturday, May 28, 2011

List and Definitions of Each UML Diagram

Use Case Diagrams
The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.
A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. As you discuss the functionality and processes of the system, you discover significant characteristics of the system that you model in the use case diagram. Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user meetings. Use case diagrams have another important use. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system
http://www.developer.com/design/article.php/2109801/Creating-Use-Case-Diagrams.htm

Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency.[1] In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

http://www.answers.com/topic/activity-diagram

Class Diagrams:
A UML class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes.
http://www.developer.com/design/article.php/2206791/The-UML-Class-Diagram-Part-1.htm

State Diagrams
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states of a component in a system. The states are specific to a component/object of a system.
A Statechart diagram describes a state machine. Now to clarify it state machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events.
http://www.tutorialspoint.com/uml/uml_statechart_diagram.htm

Interaction Diagrams
Interaction diagrams are models that describe how a group of objects collaborate in some behavior - typically a single use-case. The diagrams show a number of example objects and the messages that are passed between these objects within the use-case.
Interaction diagrams come in two forms, both present in the UML. The first form is the sequence diagram. In this form objects are shown as vertical lines with the messages as horizontal lines between them. This form was first popularized by Jacobson.
The second form of the interaction diagram is the collaboration diagram. Here the example objects are shown as icons. Again arrows indicate the messages sent in the use case. This time the sequence is indicated by a numbering scheme. Simple collaboration diagrams simply number the messages in sequence. More complex schemes use a decimal numbering approach to indicate if messages are sent as part of the implementation of another message. In addition a letter can be used to show concurrent threads.
http://www.cs.unc.edu/~stotts/145/CRC/Interactions.html

Sequence Diagram
A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system.
A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the object that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects.
http://www.developer.com/article.php/3080941

Collaboration diagram
A Collaboration diagram is easily represented by modeling objects in a system and representing the associations between the objects as links. The interaction between the objects is denoted by arrows. To identify the sequence of invocation of these objects, a number is placed next to each of these arrows.
http://www.developer.com/article.php/3102981

Package diagram
A package provides the ability to group together classes and/or interfaces that are either similar in nature or related.
http://www.developer.com/design/article.php/2206791/The-UML-Class-Diagram-Part-1.htm Package diagram shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules.
http://www.visual-paradigm.com/VPGallery/diagrams/Package.html

Component Diagram
The component diagram's main purpose is to show the structural relationships between the components of a system. In UML 1.1, a component represented implementation items, such as files and executables. Unfortunately, this conflicted with the more common use of the term component," which refers to things such as COM components. Over time and across successive releases of UML, the original UML meaning of components was mostly lost. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable" modules. But, unlike UML 1.x, components are now strictly logical, design-time constructs.
http://www.ibm.com/developerworks/rational/library/dec04/bell/

Deployment Diagram
The Deployment Diagram also helps to model the physical aspect of an Object-Oriented software system. It models the run-time configuration in a static view and visualizes the distribution of components in an application. In most cases, it involves modeling the hardware configurations together with the software components that lived on.
http://www.visual-paradigm.com/VPGallery/diagrams/Deployment.html
Deployment diagrams are used to represent the physical architecture of a system. They present the distribution of the software components on the set of execution units (nodes).
Nodes and artifacts are the main concepts in a deployment diagram.
http://support.objecteering.com/objecteering6.1/help/us/objecteering_uml_modeler/diagrams/deployment_diagrams.htm

Tuesday, May 24, 2011

Notes on Scrum from MSF for Agile Development

Points Extracted from documents available at the site of MSF for Agile


MSF for Agile Development:
• Based on Scrum, the objective of which is to “Deliver MORE value FASTER”.
• Provides customers with the opportunity to review, guide and influence your team's work as it progresses
• Based on the idea of refining plan as the team makes progress.

About Scrum:
• Methodology based on Agile Principle
• Does not attempt to define everything at the start of project, instead team works in short iterations (sprints) to refine the plan and deliver value to customer.
Major Roles Involved:
• Team Role: Most individuals are in the Team Role
• Product Owner Role: Has the responsibility that ensures that your customers are represented on the team. Must have good knowledge of customer requirement
• Scrum Master: Ensures that the scrum practices are adhered to. E.g. ensures length of scrum meetings is less than 45 min. ensure that team does not include incomplete user stories in a sprint. Ensure that product owner does not add new features to the running sprint.

Activities in Scrum:
• Prepare for the project
o Establish business case
o Assemble Team (Assign three roles to people. Two people of the team will have additional responsibility, one will be Scrum Master and other will be Product Owner).
o Set up your team’s infrastructure. (Acquire and configure the necessary software for supporting scrum).
• Plan the project
--o High level plan will be established
--o It may change during implementation
--o Output of the process is Product Backlog
----- Backlog is a list of user stories (A description of user needs and user values) (By Team)
----- Prioritized by business value and risk (By Product Owner)
----- Estimation of user stories is done in abstract units called story points. (Story points are relative values that do not translate directly into a specific number of hours. By estimating in story points, your team will provide the general size of the user stories now and develop the more detailed estimation of hours of work later) (By Team)
---- It is important that velocity is determined before planning (Velocity= total number of stories that can be covered in a sprint)
--o Output also includes Release Plan (If needed)
---- Identify groups of user stories that, together, provide enough business value to release to your customers.
---- Determine in which sprints the team expects to complete those groups of user stories.
--o Prepare for the first sprint
---- Sprint is a timeboxed iteration
---- One to Four (1 to 4) weeks long
---- Product Owner breaks the user stories down into smaller stories.
---- Product owner provide details about the user stories that the team will need to break the stories down into tasks.
---- Your team will also ask for details about the user stories to be able to break them down into tasks and estimate those tasks
• Plan a sprint
--o Sprint planning meeting
---- Team commits to completing a set of user stories from the product backlog
---- Sprint backlog is created which consist of
• Details regarding each task
• Actual hours to be spent for each task
• Total days to be consumed for a sprint
--o Choose user stories
---- Based upon the priority, user stories will be chosen for a particular sprint
---- Choice should be made based upon velocity of team
--o Identify tasks
---- Team determines the tasks it must perform to complete the story
---- They break the user stories to understand them and have confidence that it can be completed
--o Estimate Tasks
---- The Team decides how long (in hours) it will take to complete each task.
--o Commit to user stories
---- Uses iteration backlog to see if they have enough time
---- If less time is available then lower ranked user stories should be removed
• Run a sprint
--o Complete User Stories
---- Each member of your team signs up for a task when the sprint starts
---- After completing that task, the team member updates its status and sign up for another task
--o Track sprint progress
---- Daily scrum meeting of 15 minutes to maximize its chance of meeting commitments
• What I have done till last scrum meeting
• What I will do before the next
• What are the blocking issues.
--o Finish the sprint
---- Make sure that your team is completing all user stories or requirement (see if acceptance tests are being cleared )
• Track the project
--o Prepare the next sprint
--o Track release progress

Product Backlog:
• Consists of User Stories to represent what its customers need and value
• For each story the following information must be recorded
--o Who is the user
--o What the user needs to do
--o Why the user needs to do that.
• General Template: As a , I need to in order to
• Users stories should possess the INVEST characteristics
--o Independent
---- Able to be scheduled and implemented in any order
--o Negotiable and Negotiated
---- Details agreed upon with the customer
--o Valuable
---- Must be valuable to the Customer. When splitting stories for development it must be made sure that it should deliver value to customer. For e.g. designing middle tier
--o Estimable
---- Rough estimation
---- Smaller and negotiable things are easily estimated. Being Negotiable/Negotiated implies that a story is properly understood by the team.
--o Small
---- Story descriptions should be concise.
---- Stories themselves should be small and should worth not more than four person weeks of work
--o Testable
---- An important feature that can double check the clarity of requirement
---- If client does not know how a feature will be tested then he is not clear
• Low priority user stories can be kept large and can be detailed out when approached

Sprint Planning Meeting:
• 2-4 hour meeting
• Only once in a sprint
• Determine What to do in coming sprint
• Team builds Sprint Backlog on first day of sprint based upon inputs from product owner
• First half is spent in identifying stories that are important and the developers are also comfortable with it.
--o During the discussion the following information may be revealed, data sources, interface layouts, response time expectations and considerations for security and usability
--o Team learns what it must build
• In Second half, team determines how it will develop and test those user stories
--o Presence of Product Owner is also required
--o Team determines how it will implement the stories
--o Team attempts to discover whether it can commit to implement all the stories requested by Product Owner?
--o User stories are broken up into tasks
--o Estimation of each task is done in hours
--o A task should not be longer than a day
--o It must be noted that 40% of the work emerges after the sprint meeting
--o Individual estimates of tasks are added to calculate the total time required to complete the user story.
• There may be a situation that duration of task is not clear unless some other task is performed.
Daily Scrum Meeting:
• Objective is to determine what it needs to do in the next day to maximize its chances of meeting its commitments
• Duration should be limited to 15 minutes
• Each member should describe
--o What I have accomplished since most recent scrum
--o What will I accomplish before next scrum
--o What blocking issues or impediments might affect my work

UML Lecture: Methodologies

Source: people.cs.uchicago.edu/~matei/CSPP523/lect4.ppt -

Methodology

“A methodology is a collection of procedures, techniques, tools and documentation aids, supported by a philosophy, which will help the systems developers in their efforts to implement a new information system”

Methodologies are more than a collection of tools and techniques
They specify:
• The stages into which a project should be broken down
• Tasks for each stage
• Outputs produced
• Support tools to use
• How the project is to be managed and controlled
All encompassed in a philosophy

Waterfall Methodology
All phases of SDLC (Software Development Lifecycle) are executed in a sequence. Each phase completes before the next phase starts.
Philosophy of waterfall methodology
The philosophy behind waterfall seem to be that humans can do one thing at a time. Therefore, concentration should be focused on one activity and once it is completed then the other one will start.
The above philosophy is only successful when
• Requirements are known up front before design
• Requirements rarely change
• Users know what they want, and rarely need visualization
• Design can be conducted in a purely abstract space
• The technology will all fit nicely into place when the time comes
• The system is not so complex.

Problems in Waterfall
•Large amount of time and money are expanded before there is any visible results.
•Changes to requirements are difficult to manage and expensive as End-users don’t get to see the product until it is largely complete. At that time they may ask for significant changes.
•Various types of flaws remain undiscovered for lengthy period resulting in large amounts of rework when eventually discovered.

Unified Process or Rational Unified Process
Unified Process uses Unified Modelling Language (UML) although this is not necessary.
Unified Process is distinguished by being
• use-case driven
Project is managed based upon the use cases
• architecture-centric
Focus is on identifying the components and interaction among components
• iterative and incremental
Rather than a Big Bang, project is completed as small increments (which includes use-cases). While completing use cases, certain activities are performed in an iterative way. i.e. Elaboration is performed each time when we move to a new use-case

Phases of Unified Process
• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase

Inception Phase
• Initial requirements capture
• Cost Benefit Analysis
• Initial Risk Analysis
• Project scope definition
• Defining a candidate architecture
• Initial Use Case Model (10% - 20% complete)

Elaboration Phase
• Requirements Analysis and Capture
– Use Case Analysis
• Use Case (80% written and reviewed by end of phase)
• Scenarios
– Sequence and Collaboration Diagrams
– Class, Activity, Component, State Diagrams
– Detailed understanding and modeling of problem domain.
– Risk Assessment Plan revised
– Architecture Document
Construction Phase
• Focus is on implementation of the design:
– cumulative increase in functionality
– greater depth of implementation (stubs fleshed out)
– greater stability begins to appear
– implement all details, not only those of central architectural value
– analysis continues, but design and coding predominate
Transition Phase
• The transition phase consists of the transfer of the system to the user community
• It includes manufacturing, shipping, installation, training, technical support and maintenance
• Integration with existing systems (legacy, existing versions, etc.)