Assignment # 02
Fall 2010
Marks: 20
Due Date
Your assignment must be uploaded before or on 22nd November 2010.
Uploading instructions:
Please view the Assignment Submission Process document provided to you by
the Virtual University for uploading assignments.
• Assignment should be in .doc format.
• Save your assignment with your ID (e.g. bx020200786.doc).
• Assignment submission through email is highly discouraged.
Rules for Marking:
It should be clear that your assignment will not get any credit if:
• The assignment is submitted after due date.
• The submitted assignment file is corrupted.
• The assignment is copied.
Note:
Your answer must follow the below given specifications. You will be assigned zero
marks if you do not follow these instructions.
• Font style: "Times New Roman"
• Font color: "Black"
• Font size: "12"
• Bold for heading only.
• Font in Italic is not allowed at all.
• No formatting or bullets are allowed to use.
Assignment submission instructions:
Your Assignment should be a well formatted word document. Upload your assignment in
word format (ID.doc) as (bx020200786.doc).
Assignment:
Q. 01 How Facilitated Application Specification Techniques (FAST) help in
the requirement elicitation for software? Is requirement analysis and
requirements elicitation is same thing?
Q. 02 Make comparative analysis between the GOF design pattern and
GRASP design pattern with their pros and cons.
..................
solution:
CS 615_2nd_Idea Solution
Question # 1:
01 How Facilitated Application Specification Techniques (FAST) help in the
requirement elicitation for software? Is requirement analysis and requirements
elicitation is same thing?
Solution:
Effective software management plan much depends on the nature of the software itself, to
be developed. The plan can only remain successful if all the scheduled activities are
performed according to the timelines already decided. It has been observed that quite a
high amount of projects both in developing and developed countries fail despite the
organization wide process maturity. There are many factors that contribute in the
successful and on time completion of the software but the most important of the phases is
the requirement engineering in which requirement are to be fabricated and rectified again
and again to suggest the most appropriate requirements. FAST (Facilitated Application
Specification Technique) has emerged as a technology to help decrease the
communication gap between the customer and the developer. The success of FAST
session generally depends on the way the session is conducted by the facilitator
Requirement analysis
Requirements analysis, also called requirements engineering, is the process of
determining user expectations for a new or modified product. These features, called
requirements, must be quantifiable, relevant and detailed. In software engineering, such
requirements are often called functional specifications. Requirements analysis is an
important aspect of project management.
Requirements analysis involves frequent communication with system users to determine
specific feature expectations, resolution of conflict or ambiguity in requirements as
demanded by the various users or groups of users, avoidance of feature creep and
documentation of all aspects of the project development process from start to finish.
Energy should be directed towards ensuring that the final system or product conforms to
client needs rather than attempting to mold user expectations to fit the requirements.
Requirements analysis is a team effort that demands a combination of hardware, software
and human factors engineering expertise as well as skills in dealing with people.
Requirements Elicitation
Ø Standish Group listed "Lack of User Input" as most common factor of
challenged projects.
Ø Requirements Elicitation is the process of discovering the requirements for a
system by communication with customers, system users and others who have
a stake in the system development.1
Ø Development teams have to take the initiative.
Requirements elicitation is concerned with where software requirements come from and
how the software engineer can collect them. It is the first stage in building an
understanding of the problem the software is required to solve. It is fundamentally a
human activity, and is where the stakeholders are identified and relationships established
between the development team and the customer. It is variously termed "requirements
capture," "requirements discovery," and "requirements acquisition."
One of the fundamental tenets of good software engineering is that there is good
communication between software users and software engineers. Before development
begins, requirements specialists may form the conduit for this communication. They must
mediate between the domain of the software users (and other stakeholders) and the
technical world of the software engineer.
Question # 2:
Make comparative analysis between the GOF design pattern and
GRASP design pattern with their pros and cons.
Solution:
GRASP stands for General Responsibility Assignment Software Patterns
There are several GRASP patterns. Some of them are simply good design principles, and
one can argue whether they are really patterns. For example, High Cohesion and Low
Coupling are two that are well known design principles and not really patterns.
The full set of GRASP patterns are:
• Information Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations
l This approach to understanding and using design principles is based on patterns of
assigning responsibilities.
l The GRASP patterns are a learning aid to help one understand essential object
design, and apply design reasoning in a methodical, rational, explainable way.
l After identifying your requirements and creating a domain model, then add
methods to the software classes, and define the messaging between the objects to
fulfill the requirements.
l Doing:
l Doing something itself, such as creating an object or doing a calculation
l Initiating action in other objects
l Controlling and coordinating activities in other objects.
l Knowing:
l Knowing about private encapsulated data
l Knowing about related objects
l Knowing about things it can derive or calculate
l Interaction diagrams show choices in assigning responsibilities to objects.
l GRASP patterns guide choices in where to assign responsibilities.
l GRASP patterns are a codification of widely used basic principles.
l Assign a responsibility to the information expert – the class that has the
information necessary to fulfill the responsibility.
l What is a general principle of assigning responsibilities to objects?
l Who should be responsible for knowing/doing …?
l Domain model (domain expert, domain analysis) to design model
(software classes).
l Any existing to any representative.
GOF design pattern
A pattern addresses a recurring design problem that arises in specific design situations
and presents a solution to it.
There are many types of GOF design pattern we will discuss some of them
Creational Design Patterns
Singleton Design Pattern
Visitor Design Pattern
Strategy Pattern
Command Pattern
Proxy Design Pattern
Singleton Design PatternThe Singleton pattern ensures that a class has only one
instance. Provides a global point of access to that instance.
Constructor is 'PRIVATE'. This ensures that no other code in your application will be
able to create an instance of this class, by using the constructor directly. Using a static
method, which returns an object? Static variable, used for holding the created instance. If
the instance is already there, the static method do not create a second one, instead returns
the already created one. When multiple threads are introduced, you must protect the
getInstance() method through synchronization. If the getInstance() method is not
protected against synchronization, it is possible to return two different instances of the
Singleton object. Refer to Double Checked Lock (DCL) programming pattern and
ThreadLocal implementation for better singleton implementation in a multithreaded
environment.
The Proxy Design Pattern The Proxy pattern is used when you need to represent an
object that is complex or time consuming to create, by a simpler one. If creating an object
is expensive in time or computer resources, Proxy allows you to postpone this creation
until you need the actual object. A Proxy usually has the same methods as the object it
represents, and once the object is loaded, it passes on the method calls from the Proxy to
the actual object. There are several cases where a Proxy can be useful:
1. If an object, such as a large image, takes a long time to load.
2. If the object is on a remote machine and loading it over the network may be slow,
especially during peak network load periods.
3. If the object has limited access rights, the proxy can validate the accesspermissions for
that user.
The Visitor Design Pattern The Visitor pattern turns the tables on our objectoriented
model and creates an external class to act on data in other classes. This is
useful when you have a polymorphic operation that cannot reside in the class
hierarchy for some reason.. For example, the operation wasn't considered when the
hierarchy was designed, or because it would clutter the interface of the classes
unnecessarily.
TheStrategyPattern The Strategy pattern is much like the State pattern in outline,
but a little different in intent. The Strategy pattern consists of a number of related
algorithms encapsulated in a driver class called the Context. Your client program can
select one of these differing algorithms or in some cases the Context might select the
best one for you. The intent is to make these algorithms interchangeable and provide
a way to choose the most appropriate one. The difference between State and Strategy
is that the user generally chooses which of several strategies to apply and that only
one strategy at a time is likely to be instantiated and active within the Context class.
By contrast, as we have seen, it is possible that all of the different States will be
active at once and switching may occur frequently between them. In addition,
Strategy encapsulates several algorithms that do more or less the same thing, while
State encapsulates related classes that each do something somewhat different. Finally,
the concept of transition between different states is completely missing in the Strategy
pattern.
The Command Pattern The Chain of Responsibility forwards requests along a chain of
classes, but the Command pattern forwards a request only to a specific object. It encloses
a request for a specific action inside an object and gives it a known public interface. It
lets you give the client the ability to make requests without knowing anything about the
actual action that will be performed, and allows you to change that action without
affecting the client program in any way
0 comments:
Post a Comment