Packages are UML constructs that enable you to organize model elements into groups, making your UML diagrams simpler and easier to understand. Packages are depicted as file folders and can be used on any of the UML diagrams, although they are most common on use-case diagrams and class diagrams because these models have a tendency to grow.(http://www.math-cs.gordon.edu/courses/cs211/ATMExample/Package.html)
2.How is a component diagram different from a class diagram? Show an example of component diagram.
The Component Diagram helps to model the physical aspect of an Object-Oriented software system. It illustrates the architectures of the software components and the dependencies between them. Those software components including run-time components, executable components also the source code components. (http://www.google.com.ph/imgres?imgurl=http://www.visual-paradigm.com)
While a class diagram shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.
(publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.wbit.help.6012.glossary.doc/topics/glossary.html)2
(http://upload.wikimedia.org/wikipedia/commons/b/b8/Policy_Admin_Component_Diagram.PNG)
3. What is illustrated in a deployment diagram? Show an example of deployment diagram.
A deployment diagram depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. In other words, deployment diagrams show the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. You want to create a deployment diagram for applications that are deployed to several machines, for example a point-of-sales application running on a thin-client network computer which interacts with several internal servers behind your corporate firewall or a customer service system deployed using web services architecture such as Microsoft’s .NET. Deployment diagrams can also be created to explore the architecture of embedded systems, showing how the hardware and software components work together. In short, you may want to consider creating a deployment diagram for all but the mosttrivial of systems.
(http://vinci.org/uml/deploymentx.html)
4. Summarize the steps in Putting UML to work.
A. SYSTEM ANALYSIS AND DESIGN
Planning the detailed construction of the software system is the primary application of a use case. During use-case review, a system designer looks for four distinct groups of interacting system elements
Although this approach to computer system analysis is well suited to object-oriented design and development, it should be noted that it is based in formal systems analysis 5 and can be used to describe any complex system.
Figure 1: Analysis Icons (Depicting Interacting System Elements)
Figure 2: Depicting Actor to Interface Relationships
Figure 3: "Check Schedule" Sample Use-Case Analysis
Figure 3 shows a relatively simple system. This model was created directly from a sample use case (see Sidebar) by first establishing the system boundaries. This was done by inspecting for system actors and showing the system "services" that are being requested in the use case. The next step in the analysis is to study the use case Basic, Alternate, and Exceptionalprocessing flows to determine:
Where the system interface(s) will be located (usually based on the name of the use case).
Data elements and relationships (as defined within the use-case flow or supporting documentation).
Actions the system is expected to perform (based on use-case activities and illustrated by UML activity diagrams).
When creating a use case, it is important to understand 1) the nature of the information (data entities) that will be manipulated by the system, and 2) the actions for which that data is required. The data entity description illustrates one of the key features of a well-written use case, namely the capture of detailed data requirements. However, this description should focus only on the data elements and relationships themselves, rather than on any particular implementation (e.g., avoid detailing data entity Name as varchar(50), or java.lang.String). For one example of use-case data representation, please refer to the sample use case (see Sidebar). The example use-case description uses a modified technique based on Data Dictionary notation, 7 which shows elements composed of attributes or references to other elements.
Once you have a general understanding of the entities, actions, and interfaces required by the system, you can then create a more detailed Design, since the analysis has progressed to the point where code can reasonably be generated. The most commonly used UML models for design are the Class Diagram and the Sequence Diagram (Figures 4 and 5).
Figure 4: Sample Travel Schedule Class Diagram
Figure 5: Sample Check Schedule Sequence Diagram
Both the analysis and designs are added by the creation and maintenance of activity diagrams. Activity diagrams are vital to communicating information regarding process flows, as shown in the sample use case (see Sidebar). These diagrams permit the analyst to rapidly view all available paths through the use case. This is extremely helpful for discovering system controllers and process flows, as it indicates the points where system processing is expected to occur, and the nature of that processing.
The system designer can now apply the use-case flows, the system analysis, sequence diagrams, and class diagrams to further describe the detail of the system operation; data elements are mapped to specific types, architectural mechanisms (concurrency management, transactions, communication protocols, persistence mechanisms, etc.) are described, design patterns are discovered and applied, and the primary code base is created.
Figure 6: Schedule Visual Display
Figure 7: Sample Check Schedule Use-Case Activity Diagram
B. QUALITY ASSURANCE AND TESTING
Test cases are created in order to verify that the desired system functionality has been implemented by the development effort. The creation of test cases is directly tied to the functional flows detailed in the use case. Test cases are created based on the concept of a use-case scenario, which is defined as a single execution path through a use case. This is best illustrated by examining a use-case activity diagram (see Sidebar, for example). The scenario begins at the start of the diagram and selects one particular path through the execution. In this manner, all possible use-case execution paths can be exercised.
While writing a use case, you should consider the following critical points regarding the creation of test cases:
The potential error conditions (e.g., exceptional flows) should be detailed, particularly those that will have a user presentation or prevent completion of the user task.
Data essential for flow should be highlighted, as well as the requirements regarding data format and content (i.e., validation).
Entry and exit conditions for a use case should be clearly defined.
The following shows how the sequence of test cases can be derived from a simple use case:
Test Case 1: Basic Flow (positive test)
Select the View Schedule button from the main screen.
Enter the user id TESTER and the password GOFORIT in the user login screen.
The system will display the current schedule.
Test Case 2: Alternate Flow (positive test)
Follow Test Case 1.
Click on the Print Schedule button.
The printer will produce the current schedule.
Test Case 3: Exception 1 (negative test)
Select the View Schedule button from the main screen.
Enter the user id WHOOPS and the password NOPE in the user login screen.
The system should display the following error message:
You have provided an incorrect user ID and/or password; please reenter.
The system should return to the user login screen.
Test Case 4: Exception 2 (negative test)
C. CUSTOMER EXPECTATION MANAGEMENT
Use cases are a very effective tool for managing customer expectations for the system. However, although clients are often experts in their own fields, they are usually not well versed in software development methodologies. That is why you should observe the following guidelines when writing use cases:
Ensure that all technical terms are defined in a Glossary.
Avoid implementation details.
Use non-technical language whenever possible.
Maintain a consistent level of abstraction (i.e., don't include detailed descriptions with general statements of functionality).
Tell a clear, coherent story.
Be as complete as possible in the descriptions of the flows.
Review all use cases with the customer to ensure clarity and understanding.
Remember that the use case represents a contract between the development staff and the customer. Misunderstandings at the use-case development stage can have dramatic and often adverse consequences later in development.
The use case should clearly "speak" to the customer, which is particularly important during the review process. If the customer is confused about a particular flow, then you should rewrite the flow to better describe the conditions. One useful validation technique is to ask the customer to imagine their daily activities and to walk through these activities step-by-step. If the description includes steps not covered in the use case, then they should be added if they are within the scope of the system.
The reviewer should also pay particular attention to exceptional cases, since these error conditions often prevent the user from accomplishing the intended task. Make sure that the client understands and agrees to the system behavior in the event of an exception.
D. PROJECT MANAGEMENT
In this final section, I will discuss how the use case represents a key tool for project management. Although no one technique will satisfy all of the needs for project management, in my experience use cases are a very effective tool for addressing the following three project needs:
Management and mitigation of risk.
Creation and maintenance of schedules.
Control of cost and scope changes.
Use cases can be scored and ranked relative to one another based on five major criteria:
Risk - The chances of an occurrence that will prevent or seriously hamper ability to deliver the requested functionality.
Effort - The amount of personnel and development resources required to implement the functionality.
Cost - The actual cost to the business, in terms of both financial and political capital (see below).
Dependency - The natural or required order for use-case implementation (e.g., inventory must be searched for availability before assignment or purchase).
Customer Priority - The relative importance of each use case as viewed by the customer.
T.H. Athey, Systematic Systems Approach. Prentice-Hall, 1982.
A. Cockburn, "Goals and Use Cases." Journal of Object-Oriented Design, September, 1997, pp. 35-40.
E.F.J. Ecklund, L.M.L. Delcambre, and M.J. Freiling, "Change Cases: Use Cases that Identify Future Requirements." OOPSLA-96, 1996.
M. Fowler, "Use and Abuse Cases." Distributed Computing, April, 1998.
I. Jacobson et al., Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
A.M. Langer, The Art of Analysis. Springer-Verlag,1997.
D. Leffingwell and D. Widrig, Managing Software Requirements, A Unified Approach. Addison-Wesley, 2000.
B. Lieberman, " UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior." The Rational Edge, April 2001.
M.E. Model, A Professional's Guide to Systems Analysis. McGraw-Hill, 1996.
5. How important is UML for modeling.
Once you have the high level tasks defined in use cases, you can document the use case further by describing specific paths through the system. For instance, the "Edit Task" use case can have a sequence of actions through the use case as follows:
1.System presents list of tasks to user
2.User identifies which task to edit
3.User makes changes to task
4.System updates record for task
Going to this level of detail might seem overkill for such a small task, but as you understand the process, it makes larger projects that much easier to develop. It also allows someone to hand off the sub-parts of the use case to different team members, allowing well understand work to be done in parallel. In addition, this breaking the use cases down allows you to attach quantifiable measures if the tasks have requirements for things like response time. Had this Todo List manager application been required to run on a telephone with Java FX Mobile, how does the Edit Task action react when a phone call comes in?
Additionally, when defining use cases, it is best to identify test cases, too. For a single user Todo List application, the Edit Task use case is relatively easy. But, when you have a multi-user environment, the use case can have a test case of multiple users handling. By defining the appropriate response up front, before development has started, coding becomes that much easier because you already know how the system should respond for dual updates.
Part of the documenting of use cases and of a whole system's design is the creation of different diagrams. Last month you saw the aptly named use-case diagram. This is a rather crude looking diagram where the actor is literally a stick figure. As you start to learn about the different other diagrams, it is helpful to have a tool to help. Two popularly available open source options are the NetBeans 5.5 UML Modeling pack plugin and ArgoUML available through CollabNet.
These tools use something called UML, short for Unified Modeling Language, to document a system's model. The OMG standard offers a common way for system modeling so that everyone doesn't have their own way of doing things. The process began a little over ten years ago when "the Three Amigos" Grady Booch, Ivar Jacobson, and James Rumbaugh came together to adopt a common syntax that wasn't proprietary to help speed up the adoption of object-oriented technologies. While Linux was about 5 years old at the time, the open source movement and all its associated sharing was not that popular at the time. (http://java.sun.com/mailers/newsletters/fundamentals/2007/May07.html)
OUR OWN UNDERSTANDING
*
Package diagram is to identify the major components of a complete system. In ‘large systems, it is usually necessary to divide the system into various subsystem. Each subsystem function s independently from the other subsystems, although subsystems normally exchange information and frequently share the same database
*
A well-conceived and well-executed set of requirements is essential to the success of any significant software development project, and use cases have been shown to be one of the best methods for requirement solicitation, capture, and presentation. They can be used by a variety of stakeholders, including architects, designers, customers, testers, and managers. Each of these groups will have different needs that must be fulfilled by the use-case set, including discovery of system functionality, verification of desired system behavior, validation of stakeholder needs, and project organization and scope. By illustrating the multiple applications for use cases, we have shown that use cases represent an extremely flexible and powerful approach for requirements management.
