The rapid spread of mobile devices has turned the world of web design upside down. Users no longer view web content only on traditional desktop systems, but are increasingly using smartphones, tablets, and other devices with a wide range of dimensions. The challenge for web designers is to ensure that their websites look good not only on a big screen, but also on a tiny phone and everything in between.
Media queries are an excellent way to deliver different styles to different devices, providing the best experience for each type of user. A part of the CSS3 specification, media queries expand the role of the media attribute that controls how your styles are applied. For example, it's been common practice for years to use a separate style sheet for printing web pages by specifying media="print" . Media queries take this idea to the next level by allowing designers to target styles based on a number of device properties, such as screen width, orientation, and so on.
Difference between Responsive and Adaptive web design?
The hot topic for web developers and website owners is the way that websites can now automatically respond and adapt to any device with any screen size. This new way of web design optimizes the layout of the site to suit the screen size of the device it is being viewed on. There are two ways in which this can be achieve: with Responsive Web Design (RWD) and with Adaptive Web Design (AWD). Visitors to your site will not be concerned about which of the two methods you have used. This can simply come down to your or your designer’s preference. The user will not really notice a visible difference between the two methods but they do differ slightly.Adaptive is bit time consuming and expensive because you have to design multiple page layouts and render them according to device which renders it.
Responsive Web Design (RWD)
The key and important tool or elements that make up a Responsive website are CSS3, media queries, the @media rule, and fluid grids that use percentages to create a flexible foundation. It is also fundamental to use flexible images, flexible videos, fluid type and EM’s instead of pixels. All of these key points allow the responsive website to modify its layout to suit the device.
Responsive design is client-side which means the page is sent to the device browser (the client), and the browser then modifies the appearance of the page in relation to the size of the browser window.
The definition of a responsive website is that it will fluidly alter its composition to improve the accessibility of content depending on the screen size of the browser window.
Adaptive Web Design (AWD)
Adaptive web design uses predefined layouts that have been carefully constructed for a variety of screen sizes. A particular layout is activated when the screen size of the device viewing the website is detected and matched with a style sheet.
Adaptive design is predominantly server side. This means that the web server does all of the work of detecting the various devices and loading the correct style sheet depending on the attributes of the device. As well as the layout changing depending on the size of the screen they can also change depending on conditions like whether the device has a retina display or not. The server can detect this and display high quality images for retina display devices like iPads and lower quality images for standard-definition displays.
The downsides to AWD are that initial construction is very costly as you have a lot of layouts to design. Also to maintain and update all of these layouts can be very time consuming which will therefore cost a lot of money.
The definition of an adaptive website is one that has a set of predefined layouts that are activated when best suited to the device detected by the server.
Similarities and differences
The obvious similarity of both methods is that they improve accessibility of website content on mobile devices and various screen sizes. They also both provide visitors with an enhanced mobile-friendly user experience.
They are different in the way that they deliver the responsive / adaptive design to the user. RWD is dependent on fluid grids and AWD is relying on predefined size layouts. Also the fact that they either use client side or server side is another way in which they differ.
The visible difference is that responsive design will fluidly alter its layout while you resize your browser window whilst adaptive design will load a specific layout for the device you’re viewing the site on. If you resize your window with an adaptive website it will jump to a different breakpoint when you reach a screen size that suits another predefined layout.
Responsive Web Design Basics
Truth is that Web started with only webpages. We never thought that there can be anything apart from computers which will access the web page.Simple,We were not ready for other devices,When suddenly
use of mobile devices to browse the web increased ,nothing was visible on small devices properly web isn't optimized for those mobile
devices. Mobile devices are often constrained by display size and
require a different approach to render data on screen.
Let us start thinking about how to optimize our existing or new web for mobile devices..
First and foremost thing is to use VIEWPORT TAG .
How to set the viewport
Pages optimized for a
variety of devices must include a meta viewport element in the head of
the document. A meta viewport tag gives the browser instructions on how
to control the page’s dimensions and scaling.
In order to attempt to provide the best experience, mobile browsers
will render the page at a desktop screen width (usually about 980px,
though this varies across devices), and then try to make the content
look better by increasing font sizes and scaling the content to fit the
screen. For users, this means that font sizes may appear inconsistently
and they have to double-tap or pinch-zoom in order to be able to see and
interact with the content.
Using the meta viewport value width=device-width
instructs the page to match the screen’s width in device independent
pixels. This allows the page to reflow content to match different screen
sizes, whether rendered on a small mobile phone or a large desktop
monitor.
Some browsers will keep the page’s width constant when rotating to
landscape mode, and zoom rather than reflow to fill the screen. Adding
the attribute initial-scale=1 instructs browsers to
establish a 1:1 relationship between CSS pixels and device independent
pixels regardless of device orientation, and allows the page to take
advantage of the full landscape width.
Ensure an accessible viewport
In addition to setting an initial-scale, you can also set the minimum-scale, maximum-scale and user-scalable
attributes on the viewport. When set, these can disable the user’s
ability to zoom the viewport, potentially causing accessibility issues.
Size content to the viewport
On
both desktop and mobile devices, users are used to scrolling websites
vertically but not horizontally, and forcing the user to scroll
horizontally or to zoom out in order to see the whole page results in a
poor user experience.
FINALLY -----
POINTS TO REMEMBER WHILE DESIGNING RESPONSIVE WEBSITE
Use meta viewport tag to control the width and scaling of the browsers viewport.
Include width=device-width to match the screen's width in device independent pixels.
Include initial-scale=1 to establish a 1:1 relationship between CSS pixels and device independent pixels.
Ensure your page is accessible by not disabling user scaling.
Do not use large fixed width elements.
Content should not rely on a particular viewport width to render well.
Use CSS media queries to apply different styling for small and large screens.
Media queries can be used to apply styles based on device characteristics.
Use min-width over min-device-width to ensure the broadest experience.
Use relative sizes for elements to avoid breaking layout.
Media queries can be used to apply styles based on device characteristics.
Use min-width over min-device-width to ensure the broadest experience.
Use relative sizes for elements to avoid breaking layout.
Below is a list of most popular devices, along with
their resolutions and display sizes.
Anything added to a text document that conveys an extra
information. Markup languages are the languages that build the web.. That is, if we want to display a word in
some format like bold,underline... we use the corresponding markup tags for that particular
word. Thus markup describes exactly how the document should appear on the
screen or during in report processing. Markup is being used extensively not
in computing world but also in electronic documents. There are two
types of markup and hence there exists two types of markup languages. They
are procedural and generalized.
Procedural Markup Languages
- Procedural markup is typified
by its use in typesetting and publishing systems, including word processors.
Generalized Markup Languages
(GML) -
There is a major shortcoming in the procedural markup
languages. That is, if we intend to extract information from the documents,
procedural markup language is found wanting. To meet this challenge, a
generalized markup language marks up documents in a different way. The
characteristics of these languages are: 1. The elements
have logical names, rather than expressing detailed formatting instructions.
For example, an element H1 is being used to mark up text that is intended to
be a first-level header. 2. Software
applications that read documents marked up using a GML are free to present
them as they see fit, using formatting rules for particular elements that
are either defined internally, or specified elsewhere. When displayed in the
screen, the H1 element could be associated with a particular combination of
font size and weight. GML elements
usually involve both start and end tags so that the original content is
fully contained inside an element. Also there is no hint about how this
document should be presented. That is, the web browsers are free to reflect
the meanings of these elements. The most commonly used generalized markup
language is HTML for web documents and WML for mobile contents.
Generalized Markup Rule-sets
Each GML has its own elements, its own rules, and its own particular area of
application and in order for the language to function properly as a
language, those must all somehow be defined. GMLs are themselves written
using Generalized Markup Rule-sets (GMRS), also called meta-languages. The
two famous meta-languages are Standard Generalized Markup Language (SGML)
and the Extensible Markup Language (XML). In a way, XML is a subset of SGML
and WML is derived from XML. Recently another
markup language called as Extensible HTML (XHTML) for future web publishing
came out. XHTML is a reformulation of HTML 4 in XML. XHTML has to be
designed to avoid some undesirable features of HTML. Though all these
features can be accomplished easily using XML, XHTML has been formulated for
keeping the large investment made in HTML. Below is the list of markup languages :-
Application Markup
Language (AppML)
Architecture
Description Markup Language (ADML)
Artificial
Intelligence Markup Language (AIML)
ASN.1 Markup
Language (AML)
Astronomical
Instrument Markup Language (AIML)
Astronomical Markup
Language (AML)
Automatic Site Markup Language (ASML)
Bean Markup Language
(BML)
Better Markup
Language (BML)
Bibliography Markup
Language (BibML)
Bioinformatics
Sequence Markup Language (BSML)
BIOML - BIOpolymer
Markup Language
Board Game Markup
Language (BGML)
Business Rules
Markup Language (BRML)
Comics Markup
Language (ComicsML)
Chemical Markup
Language( CML)
Claris Dynamic Markup Language (CDML)
DARPA Agent Markup Language
(DAML)
Description Logic Markup Language
(DLML)
Directory Services Markup
Language (DSML)
Document Template Markup Language
(DTML)
Dynamic Hypertext Markup Language (DHTML)
Dynamic Markup Language (DML )
E-business eXtensible Markup Language (ebXML)
Earth Science Markup Language
(ESML)
Environmental Markup Language
(EML)
Financial Products Markup Language
(FpML)
eXtensible Application Markup Language (XAML)
eXtensible rights Markup Language
(XrML)
eXtensible Telephony Markup
Language (XTML)
eXtensible Graph Markup and
Modeling Language (XGMML)
eXtensible
Hypertext Markup Language (XHTML)
eXtensible
Markup Language (XML)
FAQ
Farleden Dynamic Markup Language
Field Data Markup Language (FDML)
FileMaker Dynamic Markup Language (FDML)
Financial products Markup
Language (FpML)
Financial Services Markup
Language (FSML)
Forms Data Markup Language (FDML)
Form Document Markup Language (FDML)
Forms Definition Markup Language (FDML)
Forms Markup Language (FML)
Gene Expression Markup Language
(GEML)
Geometry Description Markup
Language (GDML)
Geography Markup Language (GML)
Graffiti Markup Language (GML)
Handheld Device Markup Language (HDML)
Hypertext Markup Language (HTML)
Human Markup Language (HumanML)
Human Resources Markup Language (HRML)
ICAAP eXtended Markup Language
(IXML)
Image Markup Language (IML)
Instrument Control Markup
Language (ICML)
Instrument Markup Language (IML)
International Development Markup
Language (IDML)
Java Speech Markup Language
(JSML)
Karst Markup Language (KML)
Koala Bean Markup Language (KBML)
Lambda Markup Language (LML)
Learning Material Markup Language
(LMML)
Legal Extensible Markup Language
(LegalXML)
Liturgical Markup Language
(LitML)
Log Markup Language (LOGML)
Mail Markup Language (MML)
Maker Markup Language (MML)
Market Data Markup Language
(MDML)
Mathematical Markup Language (MathML)
Meaningful Text Markup Language
(MTML)
Medical Markup Language (MML)
Mind Reading Markup Language
(MRML)
Modest Markup Language (MML)
Multimedia Retrieval Markup
Language (MRML)
Music Markup Language (MML)
Outline Processor Markup Language
(OPML)
Opera Binary Markup Language(OBML)
Pet Name Markup Language (PNML)
Procedural Markup Language (PML)
Predictive Model Markup Language
Printing Industry Markup Language
(PrintML)
Question and Answer Markup
Language (QAML)
Quest Markup Language (QML)
Relational-Functional Markup
Language (RFML)
Research Information Exchange
Markup Language (RIXML)
ASP.NET MVC is not a new architecture pattern but the debate still goes on in
development circles as to which is better
.So, I just want to try to clear that differences and right usage of patterns.
Let we go 10-15 years back and see how web has changed..
History of the web
We've seen a number of changes in web development over the years, not always for the better:
Common Gateway Interface (CGI) - Scripting language running outside
the web server. Time and resource intensive
Microsoft Internet Database Connector (IDC) - Simple wrapper for SQL
queries, with templates to format the results
Active Server Pages (ASP) - Big step forward but mixture of HTML and
code became cumbersome and confusing. Known as "spaghetti code"
ASP.NET Web Forms - Compiled web "applications" which hides the
"statelessness" of HTTP. Allowed Windows developers to more easily
transfer to web developers. Heavy on bandwidth. Untestable.
ASP.NET MVC - Reworking of Xerox Smalltalk paradigm from the 1970's.
Works WITH statelessness nature of HTTP rather than hiding it. Removes
ViewState
Looking Back
We've seen a number
of changes in web development over the years, like: Common Gateway Interface
(CGI) - Scripting language running outside the web server. Time and resource
intensive Microsoft Internet Database Connector (IDC) - Simple wrapper for SQL
queries, with templates to format the results Scripting Active Server Pages
(ASP) - Big step forward but mixture of HTML and code became bit confusing.
Known as ASP.NET Web Forms - Compiled web "applications". It seems to take this
bit confusion away We are thinking MVC :)
Choosing Between ASP.NET Web Forms and ASP.NET MVC?
Fact is that both
are just ASP.NET server side technologies known as Active Server Pages .Now
where we split them or where is difference ? Actually these are architectural
patterns or the way we develop .net web based applications.Both can be the “best
choice” for a specific solution depending application development
requirements . When facing a decision to choose between ASP.NET Web Forms
or ASP.NET MVC it is important to know that neither technology is meant to
replace the other. Both are running parallely and are used as per project
requirement.Now, gap between two is getting filled as Microsoft is parellely including best features of MVC into ASP.NET Webform pattern also.
Some important
factors we should consider while making the choice is
If we really
need to develop application rapidly, i believe ASP.NET Web Forms pattern is
only and best choice
Unit Testing -
If TDD test driven development is not important, ASP.NET web form is best
choice.
If Application
really doesn't bother about UI scalability(UI for multiple devices) .
ASP.NET is again best choice
Apart, there are
lots of questions we need to consider before choosing architectural pattern like
Do we have
resources with good experience with Web Forms or MVC?
Because learning MVC is not simple . It has its own learning curve and needs
good time to learn.
Be sure that
we have people with JavaScript / JQuery based languages because MVC needs to
do much with these languages
Looking for
good performance without any postback? MVC is the choice but I know it point
to be debated because ASP.NET has option of AJAX
Conclusion
Truth is that
choosing MVC pattern as architectural pattern need to be justified with
strong reason otherwise it can never ever end or can lead to project failure
because you don't have mature knowledge base yet compared to ASP.NET web-forms.I
think you should be equipped with huge experience & information to make a
decision what is best for your project. The complete decision depends on your
team and project requirement.
If you think or dream of designing/developing software project, why you will think that
project is always big .We can start project of minimal functionality rather than undertaking or thinking of a large project. You start with a small project, and should never expect it to get large. If you do, you will just
over design and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the absolute size of the work you imagine. So start small, and think about the details. Don’t think
about some big picture and great design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to fly in and help you. That’s not how these things work. You need to get
something half-way useful first, and then others will feel confident on you and say, that “this almost works for me”, and they will get involved in the project automatically. Actually don’t try to be overconfident to finish
application in one go. I still remember my academics when we were assigned with some programs of addition, subtraction.. Then gradually, we modified those small programs and made it functional as calculator program. I mean
implement just one feature, and complete that. Then start another feature, and so forth. Otherwise, you will never get there. Apart, keep it clean, if at any stage your code gets a little disordered, refactor it before adding
any more features. If you try and guess how you should try and modify the system for all future requirements, you're going to get everything wrong. Either you'll end up rewriting the code you never used, or you'll be stuck
with code that sort-of does what you actually want it to do Apart, Copying and pasting text looks code in documentation part. I believe If you ever find yourself copy-and-pasting code, then that's a hint that you should pull
out the common functionality of the code.
This
Series of articles is written in almost 60 hours including sample project
development carried out as a part of the using .NET Technology stack.
Complete project can be downloaded from
Click Here to download entire solution The project is not supervised or
monitored by anyone except getting some vital feedback and clarification
from some MVP’s , whom I thank for taking time to provide me a valuable
comments and feedback in the process of designing and developing this
application
Assumptions
You have worked with Microsoft visual studio any version.
You are very familiar with classes.
You have used .net framework classes.
You can create a form in Microsoft® Visual Studio® .NET.
You are familiar with relational databases and Microsoft ADO.NET.
You have created a simple service in Microsoft® .NET.
Motivation
My
motivation for writing this series of articles and doing this project follows
the main goal of making a developers especially who want to grow as technical
architects, Projects leaders ,Mentors or Technical independent Consultants aware
and guide them in understanding End
to End project implementation which includes:-
Software development cycle SDLC
Application architecture
Solution structuring in Visual Studio
Application Packaging
Application Deployment
Regarding
which they are always wondering and shy away from taking project initiative and
trust me I have seen huge number of articles written by people without
understanding the value of the layered or tiered approach to architecture. I
know people love search engines because these search engines discover huge
number of content which they are looking for but does anyone think whether the
content is authentic? I am sure no one has time to think about it because they
are looking for something which they get.
Apart, I
Just want to make a programmer/developer comfortable to work practically on .NET
projects stick on to proper software quality processes. I believe my words can
just guide you but only your own effort of implementing my exercise or series of
articles practically can make you expert and confident to some extent. But there
is one more important thing that is Software quality process, which makes your
development visibility clean
I aim to
be more hard core developer and definitely over think about how to design or
write better code? You can take the simplest problem and ask an endless list of
questions like:
What proper design pattern can
I use here?
What is the best way to
structure my class hierarchy?
What is the best way to reduce
lines of code?
If I have created separate
layers, have I knotted them too much?
Do I have a clean separation
of code, like do I have a data access, business, Service & a UI layer?
After
you’ve defined the problem, have some draft of the UI, understand the business
rules, have a basic idea of how the code is going to look, you may find yourself
where I do need to ask the above questions. I am sure that you are thinking about how to address above questions to
get your code done?
Simply fallow below steps:-
Ask your seniors and get positive as well as negative feedback from him/her
Open .Net Framework or any free frameworks in Reflector and try to analyze how code has been written
MSDN is the biggest knowledge ocean which can guide you a lot. I love the way it has been organized
Ask MVP’S for help who run their own blogs and Forums
The whole
idea of cleaning up your code, using patterns is an art. Nobody is an expert at
anything on their first attempt, their second attempt, etc.Simple more you study
and practice and learn the better you will reach on level where you will feel
comfortable with designing great applications.
Second part deals with architecturing application as per requirement. Which wilI
include:-
Determine the Application Type
Determine the Appropriate Technologies
Determine the Deployment Strategy
Determine the Quality Attributes
Determine the Crosscutting Concerns
Solution Structuring in Visual Studio: -
Third part
deals with Solution structuring. Which will include:-
Creating Solution
Adding Project Libraries to it
Determine the Crosscutting Concerns
Application implementation in Visual Studio
Fourth part deals with writing source code. Which will include:-
Creating Classes
Writing Source Code
Application Packaging
Final part deals with packaging of
application which will include:-
Creating Solution
Adding Project Libraries to it
Determine the Crosscutting Concerns
Application Deployment
Final part deals with deployment
of application which will include :-
Creating Solution
Adding Project Libraries to it
Determine the Crosscutting Concerns
Source Code of Entire Application
Finally your source code is here http://www.skypedrive.com:-
As
mentioned that first part of this series will deal with SDLC .I know this is
theoretical so obviously boring too for coders
Planning is an objective of each and every activity, where we want to
discover things that belong to the project. An important task in creating a
software program is extracting the requirements or requirements analysis.
Customers typically have an abstract idea of what they want as an end result,
but do not know what software should do. Skilled and experienced software
engineers recognize incomplete, ambiguous, or even contradictory requirements at
this point. Frequently demonstrating live code may help reduce the risk that the
requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of
the scope of the development should be determined and clearly stated. This is
often called a scope document.Certain functionality may be out of scope of the project as a function of
cost or as a result of unclear requirements at the start of development. If the
development is done externally, this document can be considered a legal document
so that if there are ever disputes, any ambiguity of what was promised to the
client can be clarified.
Implementation
is the part of the process where software engineers actually program the code
for the project.
Software testing
is an integral and important phase of the software development process. This
part of the process ensures that defects are recognized as soon as possible.
Documenting
the internal design of software for the purpose of future
maintenance and enhancement is done throughout development. This may also
include the writing of an API, be it external or internal. The software
engineering process chosen by the developing team will determine how much
internal documentation (if any) is necessary. Plan-driven models (e.g.,
Waterfall) generally produce more documentation than Agile models.
Deployment
starts directly after the code is appropriately tested,
approved for release, and sold or otherwise distributed into a production
environment. This may involve installation, customization (such as by setting
parameters to the customer's values), testing, and possibly an extended period
of evaluation
Software training
and support is important, as software is only effective if it is used correctly
Maintaining
and enhancing software to cope with newly discovered faults or requirements can
take substantial time and effort, as missed requirements may force redesign of
the software
Software development process ,
also known as a software development life-cycle (SDLC), is a structure
imposed on the development of a software product. Similar terms include
software life cycle and software process. It is often considered a
subset of systems development life cycle. There are several models for such
processes, each describing approaches to a variety of tasks or activities that
take place during the process. Some people consider a life-cycle model a more
general term and a software development process a more specific term. For
example, there are many specific software development processes that 'fit' the
spiral life-cycle model. ISO/IEC 12207 is an international standard for software
life-cycle processes. It aims to be the standard that defines all the tasks
required for developing and maintaining software.
Several models exist to streamline the development
process. Each one has its pros and cons, and it is up to the development team to
adopt the most appropriate one for the project. Sometimes a combination of the
models may be more suitable
The figure
shows waterfall BigBang model which has several stages and are described as
below:-
Requirement stage: -
This stage takes basic business needs required for the project which is from a
user perspective so this stage produces typical word documents with simple
points or may be in a form of complicated use case documents. In this book we
will be using use case documents to describe this stage.
Design stage: -
Use case document / requirement document is the input for this stage. Here we
decide how to design the project technically and produce technical document
which has Class diagram, pseudo code etc.
Build stage:-This
stage follows the technical documents as an input so code can be generated as an
output by this stage. This is where the actual execution of the project takes
place.
Test stage:-Here
testing is done on the source code produced by the build stage and final
software is given a green flag. In this book we will have a test plan documents
for this stage.
Deliver stage: -
After succeeding in Test stage the final Article /project is finally installed
at client end for actual Articleion. This stage is start for the maintenance
stage.
Every
activity has a life cycle and software development process too is an activity.
Even if you are not aware of SDLC you still must be following it unknowingly.
But if a software professional is aware about SDLC he can execute the project in
a much controlled fashion. The greatest
benefits of this awareness is that developers especially new developers
will not
start directly coding which can
really lead to project running in an uncontrolled fashion. Second it helps
customer and software professional to avoid confusion by anticipating the
problems and issues before hand. In short SDLC defines the various stages in a
software life cycle. But before we try to understand what SDLC is all about. We
need to get a broader view of the start and end of SDLC. Any project started if
it does not have a start and end then its already in trouble. It’s like if you
go out for a drive you should know where to start and where to end or else you
are moving around endlessly.
Above is a
more global view of the how the start and end of SDLC. Any project should have
entry criteria and exit criteria. For instance a proper estimation document &
requirement document can be an entry criteria condition. That means if you do
not have a proper estimation document in place the project will not start. It
can be more practical, if half payment is not received the project will not
start. So there can be list of points which needs to be completed before a
project starts. Finally there should be end of the project also which defines
saying that this is when the project will end or sign off . For instance if all
the test scenarios given by the end customer is completed that means the project
is completed. In the above figure we have the entry criteria as an estimation
document and exit criteria as a signed document by the end client saying the
software is delivered.
Below is
the figure that shows typical flow in SDLC which has five main models .As per
use developers can select model for their project.
Water fall
Big
Bang model
Phased
model.
Iterative
Spiral
model
Incremental model.
Water fall
Let’s have
a look on Water fall model which is basically divided into two subtypes:-
Big Bang Waterfall model
The figure
shows waterfall BigBang model which has several stages and are described as
below:-
Requirement stage: -
This stage takes basic business needs required for the project which is from a
user perspective so this stage produces typical word documents with simple
points or may be in a form of complicated use case documents. In this book we
will be using use case documents to describe this stage.
Design stage: -
Use case document / requirement document is the input for this stage. Here we
decide how to design the project technically and produce technical document
which has Class diagram, pseudo code etc.
Build stage:-
This
stage follows the technical documents as an input so code can be generated as an
output by this stage. This is where the actual execution of the project takes
place.
Test stage:-
Here
testing is done on the source code produced by the build stage and final
software is given a green flag. In this book we will have a test plan documents
for this stage.
Deliver stage: -
After succeeding in Test stage the final Article /project is finally installed
at client end for actual Articleion. This stage is start for the maintenance
stage.
In this
model, it is assumed that all stages are freezed that means it’s a perfect
world. But in actual projects such processes are impractical.
Phased Waterfall model
In this
model the project is divided into small chunks and delivered at intervals by
different teams. In short, chunks are developed in parallel by different teams
and get integrated in the final project. But the disadvantage of this model is
there is improper planning may lead to fall of the project during integration or
any mismatch of coordination between the team may cause huge failure.
Iterative model
Iterative
model was introduced because of problems faced in Waterfall model. Now let’s try
to have a look on Iterative model which also has two basic subtypes as follows:-
Incremental model
In this
model work is break into parts like Waterfall model but the difference is that
in Incremental model one team can work on one or many chunks which is
contrasting from Waterfall model.
Spiral model
This model
uses series of prototype which refine on understanding of what we are actually
going to deliver. Plans are changed if required as per refining of the
prototype. So every time in this model refining of prototype is done and again
the whole process cycle is repeated.
Evolutionary model
In
Incremental and Spiral model the main problem is for any changes in between SDLC
cycle we need to iterate through the whole new cycle. For instance, During the
final(Deliver)stage client demands for change we retreat the whole cycle again
that means we need to update all the
previous (Requirement, Technical document s, Source code & Test plan) stages. In
Evolutionary model, we divide software into small units which can be earlier
delivered to the customer’s end which means we try to full fill the clients
needs. In the later stages we evolve the software with new customers needs.
Process improvement models
Capability Maturity Model Integration
The Capability
Maturity Model Integration (CMMI) is one of the leading models and based on best
practice. Independent assessments grade organizations on how well they follow
their defined processes, not on the quality of those processes or the software
produced. CMMI has replaced CMM.
ISO 9000
ISO 9000
describes standards for a formally organized process to manufacture a product
and the methods of managing and monitoring progress. Although the standard was
originally created for the manufacturing sector, ISO 9000 standards have been
applied to software development as well. Like CMMI, certification with ISO 9000
does not guarantee the quality of the end result, only that formalized business
processes have been followed.
ISO/IEC 15504
ISO/IEC 15504
Information technology — Process assessment also known as Software
Process Improvement Capability Determination (SPICE), is a "framework for the
assessment of software processes". This standard is aimed at setting out a clear
model for process comparison. SPICE is used much like CMMI. It models processes
to manage, control, guide and monitor software development. This model is then
used to measure what a development organization or project team actually does
during software development. This information is analyzed to identify weaknesses
and drive improvement. It also identifies strengths that can be continued or
integrated into common practice for that organization or team.
Agile development
Agile
software development is based on fundamental changes to what we considered
essential to software development ten years ago.
The most important thing to know about agile methods or processes is that there
is no such thing. There are only agile teams. The processes we describe as Agile
are environments for a team to learn how to be Agile.
We realize the way a team works together is far more important than any process.
While a new process can easily improve team productivity by a fraction, enabling
your team to work effectively as a cohesive unit can improve productivity by
several times. Of course to be eligible for such a big improvement you must be
working at a fraction of your potential now. Unfortunately, it isn't that
uncommon.
The most brilliant programmer’s alive working competitively in an ego-rich
environment can’t get as much done as ordinary programmers working cooperatively
as a self disciplined and self-organizing team. You need a process where team
empowerment and collaboration thrive to reach your full potential.
The second change is making the customer, the one who funds the software
development, a valuable and essential team member. When the dead line gets close
a traditional approach to reducing scope is to let the developers decide what
will work properly and what won't. Instead let the customer make scope decisions
a little at a time throughout the project.
When your customer or domain expert works directly with the development team
everyone learns something new about the problem. True domain expertise and
experience is essential to finding a simple, elegant, correct solution. A
document can have plenty of information, but real knowledge is hard to put on
paper. Left alone programmers must assume they know everything they need. When
asking questions is difficult or slow the knowledge gap grows. The system will
get built, but it won't solve the problem like one guided by an expert on a
daily basis.
Perhaps the biggest problem with software development is changing requirements.
Agile processes accept the reality of change versus the hunt for complete, rigid
specifications. There are domains where requirements can't change, but most
projects have changing requirements. For most projects readily accepting changes
can actually cost less than ensuring requirements will never change.
We can produce working software starting with the first week of development so
why not show it to the customer? We can learn so much more about the project
requirements in the context of a working system. The changes we get this way are
usually the most important to implement
Agile also
means a fundamental change in how we manage our projects. If working software is
what you will deliver then measure your progress by how much you have right now.
We will change our management style to be based on getting working software done
a little at a time. The documents we used to create as project milestones may
still be useful, just not as a measure of progress.
Instead of managing our activities and waiting till the project ends for
software, we will manage our requirements and demonstrate each new version to
the customer. It is a hard change to make but it opens up new ways to develop
software.
Take a guided tour of Agile Development by following the buttons starting here.
Or continue your guided tour of Extreme Programming by following the buttons.
Let's look at how we manage by features next.
Agile software development uses iterative development as a basis but
advocates a lighter and more people-centric viewpoint than traditional
approaches. Agile processes fundamentally incorporate iteration and the
continuous feedback that it provides to successively refine and deliver a
software system.
There are many variations of agile processes:
Extreme Programming (XP)
,
the phases are carried out in extremely small (or "continuous") steps compared
to the older, "batch" processes. The (intentionally incomplete) first pass
through the steps might take a day or a week, rather than the months or years of
each complete step in the Waterfall model. First, one writes automated tests, to
provide concrete goals for development. Next is coding (by a pair of
programmers), which is complete when all the tests pass, and the programmers
can't think of any more tests that are needed. Design and architecture emerge
out of refactoring, and come after coding. The same people who do the coding do
design. (Only the last feature — merging design and code — is common to all
the other agile processes.) The incomplete but functional system is deployed or
demonstrated for (some subset of) the users (at least one of which is on the
development team). At this point, the practitioners start again on writing tests
for the next most important part of the system.
Scrum
is the most commonly used agile process. The results from
the 7th Annual State of Agile Development Survey showed that 72% of respondents
were practicing scrum or a variation in 2012.
Rapid Application Development (RAD) Model
Rapid
application development R.A.D is a software development methodology that uses
minimal planning in favor of rapid prototyping. The "planning" of software
developed using RAD is interleaved with writing the software itself. The lack of
extensive pre-planning generally allows software to be written much faster, and
makes it easier to change requirements.RAD involves methods like iterative
development and software prototyping
According to Whitten (2004), it is a merger of various structured techniques,
especially data-driven Information Engineering, with prototyping techniques to
accelerate software systems development
In rapid application development, structured techniques and prototyping are
especially used to define users' requirements and to design the final system.
The development process starts with the development of preliminary data models
and business process models using structured techniques. In the next stage,
requirements are verified using prototyping, eventually to refine the data and
process models. These stages are repeated iteratively; further development
results in "a combined business requirements and technical design statement to
be used for constructing new systems”
This type
of model was developed by testers to emphasis the importance of early testing.
In this model testers are involved from requirement stage itself. So below is
the diagram which shows how for every stage some testing activity is done to
ensure that the project is moving as planned. For instance, In requirement stage
we have acceptance test documents created by the testers. Acceptance test
document outlines that if these test pass then customer will accept the
software. In specification stage testers create the system test document. In the
coming section system testing is explained in more elaborate fashion. In design
stage we have integration documents created by the testers. Integration test
documents define testing steps of how the components should work when
integrated. For instance you develop a customer class and Article class. You
have tested the customer class and the Article class individually. But in
practical scenario the customer class will interact with the Article class. So
you also need to test is the customer class interacting with Article class
properly. In implement stage we have unit documents created by the programmers
or testers.
Let’s try
to understand every testing phase in more detail.
Unit
Testing:
Starting from the bottom the
first test level is "Unit Testing". It involves checking that each feature
specified in the "Component Design" has been implemented in the component. In
theory an independent tester should do this, but in practice the developer
usually does it, as they are the only people who understand how a component
works. The problem with a component is that it performs only a small part of the
functionality of a system, and it relies on co-operating with other parts of the
system, which may not have been built yet. To overcome this, the developer
either builds, or uses special software to trick the component into believe it
is working in a fully functional system.
Integration Testing: As the components are
constructed and tested they are then linked together to check if they work with
each other. It is a fact that two components that have passed all their tests,
when connected to each other produce one new component full of faults. These
tests can be done by specialists, or by the developers. Integration Testing is
not focused on what the components are doing but on how they communicate with
each other, as specified in the "System Design". The "System Design" defines
relationships between components. The tests are organized to check all the
interfaces, until all the components have been built and interfaced to each
other producing the whole system.
System
Testing: Once the entire system has
been built then it has to be tested against the "System Specification" to check
if it delivers the features required. It is still developer focused, although
specialist developers known as systems testers are normally employed to do it.
In essence System Testing is not about checking the individual parts of the
design, but about checking the system as a whole. In fact it is one giant
component.
System
testing can involve a number of specialist types of test to see if all the
functional and non-functional requirements have been met. In addition to
functional requirements these may include the following types of testing for the
non-functional requirements:
Performance - Are the performance criteria met?
Volume - Can large volumes of information be handled?
Stress - Can peak volumes of information be handled?
Documentation - Is the documentation usable for the system?
Robustness - Does the system remain stable under adverse circumstances?
There
are many others, the need for which is dictated by how the system is supposed to
perform.
Acceptance Testing:
Acceptance Testing checks the
system against the "Requirements". It is similar to systems testing in that the
whole system is checked but the important difference is the change in focus:
Systems
testing checks that the system that was specified has been delivered. Acceptance
Testing checks that the system will deliver what was requested. The customer
should always do acceptance testing and not the developer. The customer knows
what is required from the system to achieve value in the business and is the
only person qualified to make that judgment. This testing is more of getting the
answer for whether is the software delivered as defined by the customer. It’s
like getting a green flag from the customer that the software is up to the
expectation and ready to be used.
Which is the best model?
In the
previous section we looked through all the models. But in real projects, hardly
one complete model can full fill the entire project requirement. In real
projects, tailor model are proven to be the best because they share features
from all models such as Waterfall, Iterative, Evolutionary models etc and can
fit in to real life time projects. Tailor model are most Articleive and
benefited for many organization. I am going to rely on Big Bang Waterfall model.
In waterfall project output of every stage will be freezed as explained earlier
no changes will be accepted once the requirement document is freezed.
What ever model
you fallow, they are almost same in terms of phases you work with .Truth
is that Choosing model is demand from client or sometimes taste.
Essential documentation in projects
In the previous section we discussed the various SDLC lifecycle models. For every stage in the model we have documents created according to phases such as:-
Requirement stage we have the Use case document
Design stage we have the Technical Design document
Build stage we have the source code
Test stage we have the Test result document
Deliver stage we have the sign off document
There is different documentation for every project and these documents change from organization to organization and obviously project to project.For instance, some organization will have 3 documents and some will have 12 documents in a project depending upon project manager or the policy of the organization to execute a project.
Let’s try to see what
each document is about:-
Requirement document:-
requirement document can be a single English document, probably a recorded audio
or video conversation or can be a complicated use case. In short it’s something
raw which comes from the end client. Estimation document: -
After getting requirement from the user we can judge cost for the project. In
this book we will be using the function point estimation model. There is a
complete chapter which is dedicated to function point in this book.
Use case document:-
document which serves as an input to the Design stage
Technical document:-
This
document contains detail of how the project being executed such as pseudo code,
class diagram, objects diagram, etc.
Test result document: -
This document is written by the testers which describe the test plan which needs
to be executed and thus giving project a green flag to Articleion.
Source code: -
This is not basically a document but one of the important deliverable which maps
to the execution phase of SDLC cycle.
Unified Modeling Language UML
The main object of UML is to make the project understanding more clear. It is a global computer industry modeling language to communicate between software professional in a project. UML helps us to create documents, artifacts & also give visualization so that we can understand the complex software engineering process of a project.
There are 12 diagrams in UML but only three views of the project from UML perspective they are as below:-
Structure diagram
Behavior diagram
Model management diagram
Structure diagram
They
are used to show static structure of an application. Let’s try to understand
what word static means here. For example
a civil Engg makes a model of a building. The outer structure of the
building will remain same but inner part of the building for instance the
structure of rooms and passages (one room, two rooms etc) can vary. Same holds
true when we talk about software industry there are static part and dynamic part
of project. For example classes in project will rarely change. Yes the
attributes and methods in the class will change as user adds new
functionalities. For instance in the below figure you can see the Invoice header
will have multiple invoice details. The structure and relation between Invoice
header and Invoice detail will never change. But yes the invoice can pass
through multiple stages like open invoice, closed invoice or pending invoice
which is dynamic.
Figure 1.5: - Project static nature
UML has four types of structure diagram:-
Class diagrams
Object diagrams
Component diagrams
Deployment diagrams
Behavior diagram
UML
gives us five Behavior diagram. They are used to show dynamic structure of an
application. Let’s try to understand what does a dynamic structure of a project
means. In a typical software project we can have business validations. Business
validations of a project are of very dynamic nature. For instance an invoice can
have lot of states for instance open invoice, closed invoice and paid invoice.
And your software will change the invoice object from one state to other state.
This is a dynamic nature of the project.
Figure
1.6: - Project behavior in action
The
above figure shows how the invoice section moves dynamically by making
transition from one state to other state. In UML to represent this kind of
dynamic nature there are five diagrams.
Use
Case diagrams
Sequence diagrams
Activity diagrams
Collaboration diagrams
State
chart diagrams
Model management diagram
Model
management diagram gives a view how different application modules are managed,
grouped and classified. For instance the below figure shows how Accounting,
Payment and common routines are grouped and organized.
Figure
1.7: - Model Management diagram in action
UML
provides three diagrams by which we can get the Model Management view. Below are
the three diagrams:-
Packages
Subsystems
Models
Overall Explanation of the UML diagrams
These are available
libraries/Diagrams in almost all the known tools like
UML
Enterprise Architect
Visio
Edraw
Class diagram Use to show real-world entities, elements of
analysis and design, or implementation classes and their relationships
Object diagram used to indicate the conditions for an event,
such as a test or an operation call
Composite structure diagram Use to show the how something is
made. Especially useful in complex structures-of structures or component-based
design
Deployment diagram Use to show the run-time architecture of the
system, the hardware platforms, software artifacts (deliverable or running
software items), and software environments (like operating systems and virtual
machines).
Component diagram Use to show organization and relationships
among the system deliverables
Package diagram Use to organize model elements and show
dependencies among them
Activity diagram Use to the show data flow and/ or the control
flow of a behavior Captures workflow among cooperating objects
Use case diagram Use to show the services that actors can
request from a system in actor and role form
State /protocol state machine diagram Use to show the life
cycle of a particular object, or the sequences an object goes through or that an
interface must support
Overview diagram Use to show many different inter- action
scenarios (sequences of behavior) for the same collaboration (a set of elements
working together to accomplish a goal)
Sequence diagram Use to focus on message exchange between a
group of objects and the order of the messages
Communication diagram Use to focus on the messages between a
group of objects and the underlying relationship of the objects
Timing diagram Use to show changes and their relationship to
clock times in real-time or embedded Systems work
Which diagram is important?
In
above table we have seen the basic use of all the UML diagrams. But in real
projects we do not draw all the
diagrams instead we look towards the complexity of the project or necessity of
the project and accordingly we decide the diagrams and then diagrams are added
to the technical document or the
requirement document. So in this series of article we will use only required
diagrams extensively:-
Use
case diagrams
Class
diagrams
Component diagram
Sequence Diagram
Let’s
try to understand them one by one:-
Use case diagram
overview
It’s a
user functionality which the user wants to be completed by the system. For
example Common scenario is that user wants to login in system. So basically it
defines the actions of the user in the system. It basically defines actions of
the system. The best way to identify a use case is by extracting verbs of the
requirement document given by the end customer/Client, which you can name as
user stories in Agile World Actors and Goals
Every use case will have the below two components actors and goals. Actors are stake
holders of the system. Stake holders provide requirement to your project and
oppose in case of any issues. Normally software users are the actors. For
instance in an accounting application accountant forms as an actor and for the
same accounting application we have cashier and charted accountant as another
form of actors for the system. Every actor has goal to perform when using the
system. There are two types of actors:-
Primary Actor:-This actor actually initiates the use case on the system.
Secondary Actor:-While
Secondary Actor contacts other actors or use cases to meet the Primary Actor’s
goal. [Picture stolen from MSDN]
The examples used in this topic relate to a Web site on which customers can
order meals from local restaurants.
An actor
(1) is a class of person,
organization, device, or external software component that interacts with
your system. Example actors are Customer
,
Restaurant
, Temperature
Sensor
, Credit Card Authorizer.
A use case
(2) represents the actions that
are performed by one or more actors in the pursuit of a particular goal.
Example use cases are Order Meal
,
Update Menu
, Process Payment
.
On a use case diagram, use cases are associated (3) with the actors that
perform them.
Your system (4)
is whatever you are
developing. It might be a small software component, whose actors are just
other software components; or it might be a complete application; or it
might be a large distributed suite of applications deployed over many
computers and devices. Example subsystems are Meal
Ordering Website
, Meal Delivery Business
,
Website Version 2
.A use case diagram can show
which use cases are supported by your system or its subsystems
In every project we have use case documents as a part of requirement gathering.
So once you go through those use case you will have good understanding of the
same.
Sequence Diagram:
Sequence Diagrams are interaction diagrams that detail how operations
are carried out
Interaction diagrams model important runtime interactions between the parts that
make up the system
Interactions Diagrams
Sequence diagrams
Interaction overview diagrams
Timing diagrams
Communication diagrams
When to Use Sequence Diagrams
You should use sequence diagrams when you want to look at the behavior of
several objects within a single use case.
Sequence diagrams are good at showing collaborations among the objects.
They are not so good at precise dentition of behaviour.
Here is the flow of events used for
the typical creating new account use case.
The Open a New Account page uses the following ASP.NET file and C# code
behind files:
NewAccount.aspx
NewAccount.aspx.cs
Sequence Diagram
Process Overview The Open a New Account process is initiated in the User Services Layer (USL).
A user inputs his or her first name, last name, password, and e-mail address.
After the USL validates the information through validator controls, it passes
the information to the Business Logic Layer (BLL) via the
FMStocks7.BLL.Account.Add method of the Account object. The BLL then
passes the information to the Data Access Layer's (DAL) AccountAdd
object. The DAL then calls the Account_Add stored procedure (SPROC) in
the SQL Server database. If the SPROC is successful, it adds the information to
the accounts table. Otherwise, it returns to the Open a New Account page and the
process is repeated. Upon successfully adding a new record to the accounts
database, the Generic Accounting Module (GAM) object additionally creates an
account with a cash balance of US$10,000.00; this is all done in a distributed
transaction. The user is then redirected to the login page and the E-Mail field
is filled in.
that we would use a second flow of events for the case where
the user is not authenticated.
So for
the same we need to document it using use case documents which is explained in
the coming section. In the next section we will go
through a use case template which we will use in most of the project. Use
case templates can be used to expand on the above diagram in more detailed way.
Detail Explanation of the Use Case template
Below
is the use case template which we will be
using in most of our project. So let’s understand every section of the template.
How do Interaction Diagrams help?
Check use cases
Check class can provide an operation { showing how a class realizes some
operation by interacting with other objects
Describe design pattern {parameterising by class provides a scheme for a
generic interaction (part of Software Architecture)
Describe how to use a component {capturing how components can interact
A web-based system is an example of a 3-tier client-server web architecture with a presentation layer, a
business logic layer, and a database layer.
The presentation layer is the
client browser with HTML and JavaScript (for interactively and data
validation).
The business logic layer is the
IIS web server with server-side processing using ASP (VBScript) and the
database server supporting T-SQL.
The data layer is a SQL database that is on the database server
In a simple web-based system
such as this, the system for the login problem could represent a combination of
a web browser with HTML (Hypertext Markup Language) using client-side JavaScript processing,
connected via HTTP (hypertext transfer protocol) to a web server running server-side ASP (Active Server Pages),
and connected via ADO (ActiveX Data Objects)
a database server supporting SQL (Structured Query Language).
We can
now improve our sequence diagram to the following using a UML sequence diagram.
The steps are summarized here as the following flow of events.
The user/Actor clicks on a link
to go to the login page or simply browses through browser using url like
www.articlegallary.com
The web browser requests the
login page from the web server.
The web server sends the login
page to the web browser
The web browser displays the
login page to the user.
The user inputs the login form.
The user clicks on the login
button.
The web browser validates the
information supplied by the user.
The web browser submits the
login form to the web server.
The web server sends the
authentication request to the database server/Active Directory
The database server requests the
relevant data from the database.
The relevant data is returned
from the database.
The database server/windows
Active directory uses this data to authenticate the user and send the result
to the web server.
The web server sends the page to
the web browser.
The web browser displays the
landing page to the user.
Class diagram
Class
is basically prototype /Template which helps us create objects. Class defines
the static structure of the project. In the below figure you can see how the
class diagram looks. Basically there are three important sections which are
numbered as shown in the below. Let’s try to understand according to the
numbering:-
Class name:-
This is
the first section or top most section of the Class which represents the name of
the Class (Article).
Attributes:-
This is the second section or
the middle section of the class which represents the properties of the system.
Methods: -
This
section carries operation or method to act on the attributes.
Figure 1.12: - Three sections of the Article class
Now we
will have a look on Association relationship between these classes
Associations in Class diagrams
A
single Class cannot represent the whole module in a project so we need one or
more classes to represent a module. For instance, a module named ‘Article
details’ cannot be completed by Article class in order to complete the whole
module we need Article class, ArticleCategory class, .. in short there is
relationship between the classes. So by grouping and relating between the
classes we create module and these are termed as Association. In order to
associate them we need to draw the arrowed lines between the classes as shown in
the below figure. In this figure, we can see Article class and the Comment class
and arrowed line showing
relationship that comment class is
shown using article class in other words order class is
going
to be used by Article class to show Article with comments. The left to right
marked arrow basically shows the flow that comment class uses the Article class.
Figure
1.13:- comment is shown by Article class
There
are four signs showing the flow:-
Figure
1.14:- Direction signs in UML
In this
Association there are two types mainly Aggregation Association and
Composition Association.
Aggregation Association
Aggregation Association signifies that the whole object can exist without the
Aggregated Object. For example in the below figure we have three classes
university class, department class and the Professor Class. The university
cannot exist without department which means that university will be closed as the department is closed. In other words lifetime of the
university depend on the lifetime of department.
Composition Association
In the
same figure we have defined second Association between the department and the
Professor. In this case, if the professor leaves the department still the
department continues in other words department is not dependent on the professor
this is called as Composition Association.
The filled
diamond represents the aggregation and the empty diamond represents the
composition. You can see the figure below for more details.
Multiplicity
Multiplicity can be termed as classes having multiple associations or one class
can be linked to instances of many other classes
Composite structure diagram
When we
try to show Aggregation and Composition discusses above in a complete project
the diagram becomes very problematical and very complex so in order to keep it
simple and visible we can use Composite structure diagram.
Reflexive associations
In many
scenarios you need to show that two instances of the same class are associated
with each other and this scenario is termed as Reflexive Association.
Figure
1.18: - Reflexive association
Generalization and specialization
In
Generalization and Specialization we define the parent-child relationship
between the classes. In many instance you will see some of the classes have same
properties and operation these classes are called super class and later you can
inherit from super class and make sub classes which have their own custom
properties. In the below figure there are three classes to show Generalization
and Specialization relationship. All phone types have phone number as a
generalized property but depending upon landline or mobile you can have wired or
simcard connectivity as specialized property. In this diagram the clsphone
represent Generalization whereas clslandline and clsmobile represents
specialization.
Figure
1.19:- Generalization and Specialization
Note: - I
Estimation
Sometime I believe that it is hard for one to estimate
unless and until you do a fine grained analysis of the system. It's one thing to
estimate effort as opposed to time. Effort calculations can be more transitive
across teams as they estimate things on basis of components, function points,
lines of code, modules, screens, etc. For me I believe
unless you're keeping a record of time spent on previous projects, how
can you expect to estimate future ones? I personally recommend just
decide on an effort metric and you continue to track your time spent
developing solutions next to it.
I believe without any historical data or previous experience you can’t provide a
promising estimation. If you don't have a SharePoint developer resource to
review your estimations (and point out architectural choices and high risk
issues), you can only rely on a scale of magnitude of accuracy. I guess
an technical resource should be part of every estimation
Testing Document
The success of every
project is keep testing….. the current project which I am doing along with this
series have simple test plan. Below is the simple paste of a sample. This is
basically an Article gallery application. The below action is when user updates
the Article details. So basically we define steps with pass and failed
conditions.
Update Article
Steps for the test:
Start the Article gallery application
Select one of the article from the article data grid. Article details will be displayed on the textboxes.
Modify some information in all the three fields.
Press Modify button Passed condition
System should save the changed information and display the newly entered data in the grid.
Failed condition: The system is not able to update the address data.
In every project we have use case documents as a part of requirement gathering.
So once you go through those use case you will have good understanding of the
same.
that we would use a second flow of events for the case where
the user is not authenticated.
The filled
diamond represents the aggregation and the empty diamond represents the
composition. You can see the figure below for more details.
