Saturday, December 19, 2009
Friday, December 11, 2009
use case formates
What is use case?
Use cases describe the system from the user's point of view. Each use case is a complete series of events, described from the point of view of the actors. it is a documenting step and are written stories.
What a use case tells or describe?
• Use cases describe the interaction between one or more actors and the system itself.
• An actor is someone with behavior.
• A system use case is normally described the functionality level of the system..
Use case templates and formats
There is no standard template for documenting detailed use cases. Standardization within each system is more important than the detail of a specific template and formats.
Use case formats
There are two types of use case formats.
• Black-box use cases
• NOT Black-box use cases
Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities.
• By defining system responsibilities with black-box use cases, it is possible to
specify what the system must do without deciding how it will do it.
Use Case Diagrams
• A use case diagram in the Unified Modeling Language is a type of behavioral diagram.
• Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals and any dependencies between those use cases and describes that what the system will do and how it will perform.
Use Case types
• Data maintenance use case:
These are typical, create, read, update, delete use cases. writing one per entity is repetitive.it is usually easier to write such usecae.
• Data analysis use case:
These use case are for analyzing transaction on entities that are manipulated by other use case.
Loyalty program use case:
These use cases allow customer to accrue the credits when using a service
Formality Types
Use cases are written in different formats, depending on need. use cases are written in varying degrees of formality:
• Brief—terse one-paragraph summary, usually of the main success scenario.
• Casual—informal paragraph format. Multiple paragraphs that cover various scenarios.
• Fully dressed—the most elaborate. All steps and variations are written in
Detail, and there are supporting sections, such as preconditions and success guarantees.
The Best Format?There isn’t one best format; some prefer the one-column style, some the two-column. Sections may be added and removed; heading names may change. None of this is particularly important; the key thing is to write the details of the main success scenario and its extensions, in some form. Summarizes many usable formats.
Use cases describe the system from the user's point of view. Each use case is a complete series of events, described from the point of view of the actors. it is a documenting step and are written stories.
What a use case tells or describe?
• Use cases describe the interaction between one or more actors and the system itself.
• An actor is someone with behavior.
• A system use case is normally described the functionality level of the system..
Use case templates and formats
There is no standard template for documenting detailed use cases. Standardization within each system is more important than the detail of a specific template and formats.
Use case formats
There are two types of use case formats.
• Black-box use cases
• NOT Black-box use cases
Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities.
• By defining system responsibilities with black-box use cases, it is possible to
specify what the system must do without deciding how it will do it.
Use Case Diagrams
• A use case diagram in the Unified Modeling Language is a type of behavioral diagram.
• Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals and any dependencies between those use cases and describes that what the system will do and how it will perform.
Use Case types
• Data maintenance use case:
These are typical, create, read, update, delete use cases. writing one per entity is repetitive.it is usually easier to write such usecae.
• Data analysis use case:
These use case are for analyzing transaction on entities that are manipulated by other use case.
Loyalty program use case:
These use cases allow customer to accrue the credits when using a service
Formality Types
Use cases are written in different formats, depending on need. use cases are written in varying degrees of formality:
• Brief—terse one-paragraph summary, usually of the main success scenario.
• Casual—informal paragraph format. Multiple paragraphs that cover various scenarios.
• Fully dressed—the most elaborate. All steps and variations are written in
Detail, and there are supporting sections, such as preconditions and success guarantees.
The Best Format?There isn’t one best format; some prefer the one-column style, some the two-column. Sections may be added and removed; heading names may change. None of this is particularly important; the key thing is to write the details of the main success scenario and its extensions, in some form. Summarizes many usable formats.
Thursday, November 19, 2009
Use Cases and Goals:
Actors have goals or needs, use applications to help satisfy them. Consequently,
an EBP-level use case is called a user goal-level user case, to emphasize
that it serves (or should serve) to fulfill a goal of a user of the system, or the
primary or main actor.
This is slight shift in emphasis for the use-case modeler. Rather than asking
"What are the use cases?", one starts by asking: "What are your goals?" In fact,
the name of a use case for a user goal should reflect its name, to emphasize this
viewpoint.Goal: capture or process a sale; use case: Process Sale.
Note that because of this symmetry, the EBP guideline can be equally applied to
decide if a goal or a use case is at a suitable level.
Imagine we are together in a requirements workshop. We could ask either:
. "What do you do?" (roughly a use case-oriented question) or,
. "What are your goals?"
Answers to the first question are more likely to reflect current solutions and
procedures, and the complications associated with them.
Answers to the second question, especially combined with an investigation to
move higher up the goal hierarchy ("what is the goal of that goal?") open up
the vision for new and improved solutions, focus on adding business value,
and get to the heart of what the stakeholders want from the system under
discussion.
Applying the EBP Guideline
you are investigating user goals. The conversation goes like this: During a
requirements workshop:
Requirements for use case of a system:
System analyst: "What are some of your goals in the context of using a POS
system?"
Cashier: "One, to quickly log in. Also, to capture sales."
System analyst: "What do you think is the higher level goal motivating logging
in?"
Cashier: "I’m trying to identify myself to the system, so it can validate that
I’m allowed to use the system for sales capture and other tasks."
System analyst: "Higher than that?"
Cashier: "To prevent theft, data corruption, and display of private company
information."
Note the analyst’s strategy of searching up the goal hierarchy to find higher
level user goals that still satisfy the EBP guideline, to get at the real intent
behind the action, and also to understand the context of the goals.
"Prevent theft, ..." is higher than a user goal; it may be called an enterprise goal,
and is not an EBP. Therefore, although it can inspire new ways of thinking
about the problem and solutions (such as eliminating POS systems and cashiers
completely), we will set it aside for now.
Lowering the goal level to "identify myself and be validated" appears closer to
the user goal level. But is it at the EBP level? It does not add observable or measurable
business value. If the CEO asked, "What did you do today?" and you
said "I logged in 20 times!", she would not be impressed. Consequently, this is a
secondary goal, always in the service of doing something useful, and is not an
EBP or user goal. By contrast, "capture a sale" does fit the criteria of being an
EBP or user goal.
As another example, in some stores there is a process called "cashing in", in
which a cashier inserts their own cash drawer tray into the terminal, logs in,
and tells the system how much cash is in drawer. Cashing In is an EBP-level (or
user goal level) use case; the log in step, rather than being a EBP-level use case,
is a subfunction goal in support of the goal of cashing in.
Goals and Use Cases Can Be Composite:
Goals are usually composite, from the level of an enterprise to
many supporting intermediate goals while using applications
to supporting subfunction goals within applications .
Similarly, use cases can be written at different levels to satisfy these goals, and
can be composed of lower level use cases
an EBP-level use case is called a user goal-level user case, to emphasize
that it serves (or should serve) to fulfill a goal of a user of the system, or the
primary or main actor.
This is slight shift in emphasis for the use-case modeler. Rather than asking
"What are the use cases?", one starts by asking: "What are your goals?" In fact,
the name of a use case for a user goal should reflect its name, to emphasize this
viewpoint.Goal: capture or process a sale; use case: Process Sale.
Note that because of this symmetry, the EBP guideline can be equally applied to
decide if a goal or a use case is at a suitable level.
Imagine we are together in a requirements workshop. We could ask either:
. "What do you do?" (roughly a use case-oriented question) or,
. "What are your goals?"
Answers to the first question are more likely to reflect current solutions and
procedures, and the complications associated with them.
Answers to the second question, especially combined with an investigation to
move higher up the goal hierarchy ("what is the goal of that goal?") open up
the vision for new and improved solutions, focus on adding business value,
and get to the heart of what the stakeholders want from the system under
discussion.
Applying the EBP Guideline
you are investigating user goals. The conversation goes like this: During a
requirements workshop:
Requirements for use case of a system:
System analyst: "What are some of your goals in the context of using a POS
system?"
Cashier: "One, to quickly log in. Also, to capture sales."
System analyst: "What do you think is the higher level goal motivating logging
in?"
Cashier: "I’m trying to identify myself to the system, so it can validate that
I’m allowed to use the system for sales capture and other tasks."
System analyst: "Higher than that?"
Cashier: "To prevent theft, data corruption, and display of private company
information."
Note the analyst’s strategy of searching up the goal hierarchy to find higher
level user goals that still satisfy the EBP guideline, to get at the real intent
behind the action, and also to understand the context of the goals.
"Prevent theft, ..." is higher than a user goal; it may be called an enterprise goal,
and is not an EBP. Therefore, although it can inspire new ways of thinking
about the problem and solutions (such as eliminating POS systems and cashiers
completely), we will set it aside for now.
Lowering the goal level to "identify myself and be validated" appears closer to
the user goal level. But is it at the EBP level? It does not add observable or measurable
business value. If the CEO asked, "What did you do today?" and you
said "I logged in 20 times!", she would not be impressed. Consequently, this is a
secondary goal, always in the service of doing something useful, and is not an
EBP or user goal. By contrast, "capture a sale" does fit the criteria of being an
EBP or user goal.
As another example, in some stores there is a process called "cashing in", in
which a cashier inserts their own cash drawer tray into the terminal, logs in,
and tells the system how much cash is in drawer. Cashing In is an EBP-level (or
user goal level) use case; the log in step, rather than being a EBP-level use case,
is a subfunction goal in support of the goal of cashing in.
Goals and Use Cases Can Be Composite:
Goals are usually composite, from the level of an enterprise to
many supporting intermediate goals while using applications
to supporting subfunction goals within applications .
Similarly, use cases can be written at different levels to satisfy these goals, and
can be composed of lower level use cases
Iterative development:
Iterative development is a skillful approach to software development, and lies at
the heart of how OOA/D is presented. The Unified Process is an
example of iterative process for projects using OOA. Informally, a software development process describes an approach to building, deploying, and possibly maintaining software.
The Unified Process has emerged as a popular software development process for building
object-oriented systems. In particular, the Rational Unified Process or RUP.
RUP is an example of up.
ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS
A detailed refinement of the Unified Process, has been widely adopted.
The Unified Process combines commonly accepted best practices, such as
an iterative lifecycle and risk-driven development, into a cohesive and well-documented
description.
.UP practices provide an example structure to talk about how to do—and
how to learn—OOA/D.
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages team-work, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis.
Iterative and Incremental development is a cyclic software development process developed .
Iterative Development adds agility to the development process. Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant through out the project. This is the heart beat of your project. It is this constant that makes measuring progress and planning simple and reliable in XP.
Don't schedule your programming tasks in advance. Instead have an iterationship planning meeting at the beginning of each iteration to plan out what will be done. Just-in-time planning is an easy way to stay on top of changing user requirements.
It is also against the rules to look ahead and try to implement anything that it is not scheduled for this iteration. There will be plenty of time to implement that functionality when it becomes the most important story in the release plan.
Iteration is best way and approach for any system, because it develop the system incremently. And changes can be done in the system even latter because it is adoptive as well. It is flexible also. Thats why mostly programmers use this method and prefer it. In this methods system is divided into parts or subsystems. and each subsystem is a syatem itselfe. and each subsystem tests, construct and its own development phases.
example of iterative process for projects using OOA. Informally, a software development process describes an approach to building, deploying, and possibly maintaining software.
The Unified Process has emerged as a popular software development process for building
object-oriented systems. In particular, the Rational Unified Process or RUP.
RUP is an example of up.
ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS
A detailed refinement of the Unified Process, has been widely adopted.
The Unified Process combines commonly accepted best practices, such as
an iterative lifecycle and risk-driven development, into a cohesive and well-documented
description.
.UP practices provide an example structure to talk about how to do—and
how to learn—OOA/D.
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages team-work, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis.
Iterative and Incremental development is a cyclic software development process developed .
Iterative Development adds agility to the development process. Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant through out the project. This is the heart beat of your project. It is this constant that makes measuring progress and planning simple and reliable in XP.
Don't schedule your programming tasks in advance. Instead have an iterationship planning meeting at the beginning of each iteration to plan out what will be done. Just-in-time planning is an easy way to stay on top of changing user requirements.
It is also against the rules to look ahead and try to implement anything that it is not scheduled for this iteration. There will be plenty of time to implement that functionality when it becomes the most important story in the release plan.
Iteration is best way and approach for any system, because it develop the system incremently. And changes can be done in the system even latter because it is adoptive as well. It is flexible also. Thats why mostly programmers use this method and prefer it. In this methods system is divided into parts or subsystems. and each subsystem is a syatem itselfe. and each subsystem tests, construct and its own development phases.
Unified Modeling Language
The UML:
Defination:The Unified Modeling Language (UML) is a language for specifying,
visualizing, constructing, and documenting the artifacts of software systems,as
well as for business modeling and othernon-software systems.
Use cases very simple and convenient way of requirements, and these all types of diagrams are included in use cases.
UML includes a set of graphical notation techniques to create visual models of software systems. The Unified Modeling Language pushes the envelope of what can be done with existing methods..
INTRODUCTION:
Basically UML is used for graphical representation of models of systems.
The UML has emerged as the de facto and de jure standard diagramming notation
for object-oriented modeling. It started as an effort by Grady Booch and Jim
Rumbaugh in 1994 to combine the diagramming notations from their two popular methods—the Booch and OMT methods. They
joined by Ivar Jacobson, the creator of the Objectory method, and as a group came to be known as the three amigos. Many others contributed to the
UML, perhaps most notably Cris Kobryn, a leader in its rapidly increasing refinements.
The UML was adopted in 1997 as a standard by the OMG, and has continued to be refined in new
In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so repositioning the work on a unified method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP.
Modeling types:
There are different types of models :
1)Business modeling
2)Dynamical modeling
3)Logical or class modeling
4)Physical development modeling
Development Applications:
1)Reverse Engineering Java Applications
2)Creating Use Case Diagrams
3)Creating Class Diagrams
4)Creating Activity Diagrams
5)NetBeans UML Custom Code Generation
6)Synchronizing Source in NetBeans 6.5
7)NetBeans UML 6.5 Keyboard Shortcuts
These are included in the modeling of a system.
Use-case diagrams:
Use case is are written stories about system,so that user can understand the functionality of system.A use case describes a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (the person with some activity or behaviour) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases -- either all use cases for the complete system, or a breakout of a particular group of use cases with their functionality and performance.
To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To represent an actor on a use-case diagram, you draw a stick person to the left or right. Use simple lines to show relations between actors and use cases.
Sequence diagrams:
Sequence diagrams show a detailed flow for a particular use case or even just part of a particular use case.They show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects like flow of messages.
A sequence flow of diagram is very simple to draw. Across the top of your diagram, identify the class objects by putting each class objects inside a box. In the box, put the class object name and class name separated by a space or colon. If a class object sends a message to another class object, draw a line with an open arrowhead pointing to the receiving class object; place the name of the message or method above the line.
Reading a sequence diagram is a very simple way. Start from top left corner with the class object that starts the sequence or flow. Then follow each message towards down the diagram.
Deployment diagram:
The deployment diagram shows how a system will be physically deployed in the hardware environment and physical representation of diagrams is a most important way that help to understand the system for user. Its shows where the different parts of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime.
The representations in a deployment diagram contains the notation elements used in a component diagram, with some additions, that also including the concept of a node. A node represents either a physical machine or a virtual machine node. To model a node, simply draw a three-dimensional cube with the name of the node at the top of that cube.
UML(unified modeling language) is a standardized general-purpose modeling of objects and is language in the field of software.
visualizing, constructing, and documenting the artifacts of software systems,as
well as for business modeling and othernon-software systems.
Use cases very simple and convenient way of requirements, and these all types of diagrams are included in use cases.
UML includes a set of graphical notation techniques to create visual models of software systems. The Unified Modeling Language pushes the envelope of what can be done with existing methods..
INTRODUCTION:
Basically UML is used for graphical representation of models of systems.
The UML has emerged as the de facto and de jure standard diagramming notation
for object-oriented modeling. It started as an effort by Grady Booch and Jim
Rumbaugh in 1994 to combine the diagramming notations from their two popular methods—the Booch and OMT methods. They
joined by Ivar Jacobson, the creator of the Objectory method, and as a group came to be known as the three amigos. Many others contributed to the
UML, perhaps most notably Cris Kobryn, a leader in its rapidly increasing refinements.
The UML was adopted in 1997 as a standard by the OMG, and has continued to be refined in new
In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so repositioning the work on a unified method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP.
Modeling types:
There are different types of models :
1)Business modeling
2)Dynamical modeling
3)Logical or class modeling
4)Physical development modeling
Development Applications:
1)Reverse Engineering Java Applications
2)Creating Use Case Diagrams
3)Creating Class Diagrams
4)Creating Activity Diagrams
5)NetBeans UML Custom Code Generation
6)Synchronizing Source in NetBeans 6.5
7)NetBeans UML 6.5 Keyboard Shortcuts
These are included in the modeling of a system.
Use-case diagrams:
Use case is are written stories about system,so that user can understand the functionality of system.A use case describes a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (the person with some activity or behaviour) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases -- either all use cases for the complete system, or a breakout of a particular group of use cases with their functionality and performance.
To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To represent an actor on a use-case diagram, you draw a stick person to the left or right. Use simple lines to show relations between actors and use cases.
Sequence diagrams:
Sequence diagrams show a detailed flow for a particular use case or even just part of a particular use case.They show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects like flow of messages.
A sequence flow of diagram is very simple to draw. Across the top of your diagram, identify the class objects by putting each class objects inside a box. In the box, put the class object name and class name separated by a space or colon. If a class object sends a message to another class object, draw a line with an open arrowhead pointing to the receiving class object; place the name of the message or method above the line.
Reading a sequence diagram is a very simple way. Start from top left corner with the class object that starts the sequence or flow. Then follow each message towards down the diagram.
Deployment diagram:
The deployment diagram shows how a system will be physically deployed in the hardware environment and physical representation of diagrams is a most important way that help to understand the system for user. Its shows where the different parts of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime.
The representations in a deployment diagram contains the notation elements used in a component diagram, with some additions, that also including the concept of a node. A node represents either a physical machine or a virtual machine node. To model a node, simply draw a three-dimensional cube with the name of the node at the top of that cube.
UML(unified modeling language) is a standardized general-purpose modeling of objects and is language in the field of software.
Wednesday, November 18, 2009
what is analysis and design?
Analysis:
emphasize an investigation of the problem and requirements rather than a solution .for example if a new computerized library information system is desired,how will it be used?Analysis is a broad term, be qualified, as in requirements analysis or obje analysis.
Design:
Data Structures and Algorithms with Object-Oriented Design Patterns in C++
Ultimately design can be implemented.
As with analysis, the term is best qualified, as an object design or database design.
What is object oriented analysis and design?
During object oriented analysis, there is an emphasis on finding and describing the objects or concepts in the problem domain. For example in the case of the library information system, some of the concepts include Book, Library and patron.
Basically,it is a software engineering approach that models a system as a group of interrelated objects. Each object represents some objects of interest in the system being modeled, and is known by its class, its state and its behavior. Various models in a system can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects.
Object-oriented analysis OOA/D applies object-modeling techniques to analyze the functional requirements for a system, elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system can do that.
Define use case:
Requirements analysis may include a description of related domain processes, these can be written as use case.
Use case:
are not object oriented artifacts they are simple written stories. However they are popular tools in requirements analysis and are important part of the unified process.
For example here is a brief description of a Dice game.
"play a dice game: a player picks up and roll the dice. if the die face value total seven, the wins otherwise they lose"
Problem Domain:
Object-oriented analysis looks at the problem domain with the aim of producing a imaginary model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design. Analysis is done before the Design because it is necessary to investigate about the project or system that the user need.
The sources for the analysis can be a written requirements statement, a formal vision document, interaction with stakeholders or other necessary parties. A system may be divided into multiple parts, representing different types and works, technological, or other areas of system, each of which are analyzed and describe separately.
There are many important parts on which a software or a system depends; like
1)Interaction diagrams.
2)UML class diagrams.
3)User interface
4)Requirements
5)Construction faces
•Pattern name:
a pattern name should really reflect the meaning of what it is abstracting. It should be simple so that one can refer to it during analysis.
•Object:
A scenario that illustrates the problem and how the analysis pattern contributes to the solution in the concrete scenario
•Necessities and context:
Discussion of forces and tensions which should be resolved by the analysis pattern
•Solution:
Description of solution and of the balance of forces achieved by the analysis pattern in the scenario in the motivation section. Includes all relevant structural and behavioural aspects of the analysis pattern.
•Consequences:
this should emphasise how the goal is achieved by the analysis pattern with its limitation.
•Design:
Suggestions of design implementations of this pattern.
emphasize an investigation of the problem and requirements rather than a solution .for example if a new computerized library information system is desired,how will it be used?Analysis is a broad term, be qualified, as in requirements analysis or obje analysis.
Design:
Data Structures and Algorithms with Object-Oriented Design Patterns in C++
Ultimately design can be implemented.
As with analysis, the term is best qualified, as an object design or database design.
What is object oriented analysis and design?
During object oriented analysis, there is an emphasis on finding and describing the objects or concepts in the problem domain. For example in the case of the library information system, some of the concepts include Book, Library and patron.
Basically,it is a software engineering approach that models a system as a group of interrelated objects. Each object represents some objects of interest in the system being modeled, and is known by its class, its state and its behavior. Various models in a system can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects.
Object-oriented analysis OOA/D applies object-modeling techniques to analyze the functional requirements for a system, elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system can do that.
Define use case:
Requirements analysis may include a description of related domain processes, these can be written as use case.
Use case:
are not object oriented artifacts they are simple written stories. However they are popular tools in requirements analysis and are important part of the unified process.
For example here is a brief description of a Dice game.
"play a dice game: a player picks up and roll the dice. if the die face value total seven, the wins otherwise they lose"
Problem Domain:
Object-oriented analysis looks at the problem domain with the aim of producing a imaginary model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design. Analysis is done before the Design because it is necessary to investigate about the project or system that the user need.
The sources for the analysis can be a written requirements statement, a formal vision document, interaction with stakeholders or other necessary parties. A system may be divided into multiple parts, representing different types and works, technological, or other areas of system, each of which are analyzed and describe separately.
There are many important parts on which a software or a system depends; like
1)Interaction diagrams.
2)UML class diagrams.
3)User interface
4)Requirements
5)Construction faces
•Pattern name:
a pattern name should really reflect the meaning of what it is abstracting. It should be simple so that one can refer to it during analysis.
•Object:
A scenario that illustrates the problem and how the analysis pattern contributes to the solution in the concrete scenario
•Necessities and context:
Discussion of forces and tensions which should be resolved by the analysis pattern
•Solution:
Description of solution and of the balance of forces achieved by the analysis pattern in the scenario in the motivation section. Includes all relevant structural and behavioural aspects of the analysis pattern.
•Consequences:
this should emphasise how the goal is achieved by the analysis pattern with its limitation.
•Design:
Suggestions of design implementations of this pattern.
Monday, October 12, 2009
what is software engineering?
Hi,
I m trying to introduce you about software engineering.My research is not so wast
And powerfull,but I will try my best to introduce you about this field as much as
possible.
I m trying to introduce you about software engineering.My research is not so wast
And powerfull,but I will try my best to introduce you about this field as much as
possible.
Introduction:
A knowledge of programming or software is the main pre-requisite to becoming a software engineer, but it is not sufficient. Many software engineers have degrees but due to the unconciousness of software engineering programs they can not perform well.and have not much idea about programming. This has started to change with the introduction of new software engineering degrees.Now almost in every field all software are used.
It is like instructions,to run any machienary we need instructions and some software that can make it to work.The concept of software was first time introduced in 1968.It relates to many other fields.It is like a bridge between different different engineering fields.
Almost every type of work related to it.
For development of software we usually use different methods.
There are many types of methods for development like:
1) Iterative development
2) Waterfall development
Defination:
software engineering is the branch of engineering which deals with systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.Its all about the softwares that use in almost every field.its is a study of programming coading and instructions.study of these approaches; that is, the application of softwae engineering.First time sofware engineering was introduced in 1968.it has continued as a profession and field of study dedicated to creating software that is of higher quality, more affordable, maintainable, and quicker to build. Since the field is still relatively young compared to other fields of engineering, there is still much debate around whatsoftware engineering actually is, and if it conforms to the classical definition of engineering.
Titlesthere are some related topics to be discussed in software engineering
Titlesthere are some related topics to be discussed in software engineering
1 Intoduction
2 History of software engineering
3 Professions related to software
4 Employment
5 globalization
6 Education
7 Disciplines
8 Sub-disciplines
9 Computer sciences
10 Systems engineering
11 References
2 History of software engineering
3 Professions related to software
4 Employment
5 globalization
6 Education
7 Disciplines
8 Sub-disciplines
9 Computer sciences
10 Systems engineering
11 References
History:
First time computer was introduced in 1940.there was many problems to handle it.To work with only a part of hardware like any digital machiene was very difficult.software started to appear in the early 90s in the form of linux and other software introducing the "bazaar" or decentralized style of constructing software.Because of these problems we need a language that can handle the hardwares To work properly.So that was the first time the idea of programming came in mind .Different languges came like C, C++,and then java the advanced version of C++ language.So first language was introduced in 1970.
First time computer was introduced in 1940.there was many problems to handle it.To work with only a part of hardware like any digital machiene was very difficult.software started to appear in the early 90s in the form of linux and other software introducing the "bazaar" or decentralized style of constructing software.Because of these problems we need a language that can handle the hardwares To work properly.So that was the first time the idea of programming came in mind .Different languges came like C, C++,and then java the advanced version of C++ language.So first language was introduced in 1970.
Reasons:
Computer language innovation and development occurs for two fundametal reasons
1) to adapt to changing enviornment and uses.
2) To implement refinements and improvements in the art of programming.
Although softwares like laguages has inseparably linked with the online enviornment of the internet.The C++ languages shook the computer world.
When computer language is designed ,trade offs are often made such as the following:
1) Easy-of use versus.
2) Safety versus efficiency
3) Rigidity versus extensibility
Profession:
In the UK, the British computer society licenses software engineers and members of the society can also become charted engineers (CEng), while in Canada, software engineers can hold the Professional Engineer (P.Eng)designation and/or the Information Systems Professional (I.S.P.) designation; however, there is no legal requirement to have these Software and Systems
Engineering Vocabulary published on-line by the IEEE Computer Societyualifications.But in some area like canada and Quebec there are no facilites for software engineers.
Employment:
Most software engineers work as employees or contractors. Software engineers work with businesses, government agencies and non-profit organizations. Some software engineers work for themselves as freelancers. Some organizations have specialists to perform each of the tasks in the software development processes. Other organizations require software engineers to do many or all of them. In large projects, people may specialize in only one role. In small projects, people may fill several or all roles at the same time. Specializations include: in industry and in academies.They work like an organization for development of different softwares.
Globalization:
Most of students in the development have avoided degrees related to software engineering because of the fear of offshore outsourcing and of being displaced by foreign visa workersAlthough government statistics do not currently show a threat to software engineering itself; and computer programmingdoes appear to have been affected by this.usually one is expected to start out as a computer programmer before being promoted to software engineer. Thus, the career path to software engineering may be rough, especially during descions and requirements .and the main part of devlopment is the requirment gathering.Some career counselors suggest a student also focus on "people skills" and business skills rather than purely technical skills because such "soft skills" are allegedly more difficult to offshore.
Most software engineers work as employees or contractors. Software engineers work with businesses, government agencies and non-profit organizations. Some software engineers work for themselves as freelancers. Some organizations have specialists to perform each of the tasks in the software development processes. Other organizations require software engineers to do many or all of them. In large projects, people may specialize in only one role. In small projects, people may fill several or all roles at the same time. Specializations include: in industry and in academies.They work like an organization for development of different softwares.
Globalization:
Most of students in the development have avoided degrees related to software engineering because of the fear of offshore outsourcing and of being displaced by foreign visa workersAlthough government statistics do not currently show a threat to software engineering itself; and computer programmingdoes appear to have been affected by this.usually one is expected to start out as a computer programmer before being promoted to software engineer. Thus, the career path to software engineering may be rough, especially during descions and requirements .and the main part of devlopment is the requirment gathering.Some career counselors suggest a student also focus on "people skills" and business skills rather than purely technical skills because such "soft skills" are allegedly more difficult to offshore.
Sub-disciplines:
1)Software requirements.
2)Software design, Computer-Aided Software Engineering
3)Software development
4)Software testing
5)Software maintenance:
6)Software development process.
7)Computer Aided Software Engineering
8)Software quality
1)Software requirements.
2)Software design, Computer-Aided Software Engineering
3)Software development
4)Software testing
5)Software maintenance:
6)Software development process.
7)Computer Aided Software Engineering
8)Software quality
Subscribe to:
Posts (Atom)