CmpE 232 – Component-Based and

Reuse-Oriented SW Engineering

Practice Problem (5)

______

This problem statement was developed by

Team: OPORD

Member: Rollie Olson, Robert Durtschi, Buu Che, and James Leege

______

Part 1: Component-Based Software Development

Answer the following questions:

(1) Document all of the Use Cases in Your Problem:

(a) Identify two of the use cases

(b) Identify Actors and their roles

(c) Identify corresponding classes

(d) Describe the Use Case

Repeat the process for at least two of the use cases.

Use the following Use Case Template to document your Use Cases

All the fields must be filled for each use case.

1. Use Case Id.

2. Use Case Title

  1. Actors & Corresponding Roles
  2. Classes

5. Corresponding Attributes

6. Corresponding Interfaces (services or operations)

7. Use Case Description – Feel free to use pre- and post-conditions where appropriate.

8. Alternatives

(2) Create CRC cards for the existing classes.

(CRC stands for Class Responsibility and Collaborations)

(3) Prepare traditional models for this problem showing at least 10 relationships among the object classes in this problem, including associations, aggregations, and generalizations. Show multiplicities in your diagrams. You must name attributes and operations for each class. Use association and role names when needed.

(4) Create Sequence diagrams. Sequence diagrams will be used to "realize" Use Cases. All Use cases should be described through sequence diagrams. The sequence diagrams can describe the same Use Cases that a flow of events was created for in the Use Case portion of the assignment.

(5) Create Components diagrams for as many components in your project as you wish, and show all the interfaces, usage dependencies, ports, and connectors. Document the component diagrams. Address implementation issues that are related to these component diagrams if any.

Please submit your answer electronically as MS word documents before the next lecture. – Feel free to submit all diagrams in Rational Rose or Visio formats

Part 2: Stable Pattern-Based Software Development

(1) Use Cases. Update #1.Document all use case templates with software stability in mind. Use the following template to document your use cases.

1. Use Case Id.

2. Use Case Title

3. Actors & Corresponding Roles

4. Classes

  1. Corresponding Attributes
  2. Corresponding Interfaces
  3. Class Classification: EBTs, BOs, IOs
  4. Use Case Description
  1. Alternatives

(2) Create or/and update all the CRC cards for all the (EBTs, BOs, Roles) in your stability model of your team project (CRC stands for Class Responsibility and Collaborations).

(3) Class diagram (Stability Model). Create a new Class diagram of your team problem based on the EBTs, BOs, and IOs – Describe your stability model. Class descriptions should include all attributes and methods for the class. All class relationships (associations, aggregations, dependencies, and specializations) should be included in the class diagram. association classes, interface classes, constraints, interfaces, tagged values and/or stereotypes, and notes must be included in the class diagram.

(4) Sequence diagrams. Create Sequence diagrams with stability in mind that will be used to "realize" Use Cases. All Use cases should be described through sequence diagrams. The sequence diagrams can describe the same Use Cases that a flow of events was created for in the Use Case portion of the assignment.

(5) Create Components (or Stable Patterns) diagrams based on Software Stability for as many components (Patterns) in your project as you wish, and show all the interfaces, usage dependencies, ports, and connectors. Document the component (stable pattern) diagrams. Address implementation issues that are related to these component diagrams if any.

Please submit your answer electronically as MS word documents before the next lecture. – Feel free to submit all diagrams in Rational Rose or Visio formats

______

Personal Digital Assistants in the Modern Battlefield

Briefing of Dismounted Soldiers on Operations Orders

ABSTRACT

“In an attempt to remove as much chance of misunderstanding as possible, this communications process of intent and orders has been refined over the years. Military terms are used, each with a specific meaning, and maps and other graphic symbols are also used, each with it’s own specific meaning. In spite of this, normal human dynamics, chance occurrences, and enemy actions lead to misinterpretations…”[1]

“Since the entire process of battle command – problem solving, dissemination of the solution, and actual physical execution – tends to take a long time, commanders are always looking for ways to reduce that time”[2]

“The targets I have chosen are shown on my map. Make sure you mark them on your map before you leave.”[3]

The situation described by General Franks has improved greatly since Desert Storm in 1991. Almost all vehicles in the modern United States Army contain an embedded computer system that can display warning orders, operation orders (OPORD), or fragmentary orders (FRAGO). These orders can be loaded directly to the computer using a special device, or received over the tactical internet, also a quite recent development. The soldier who is mounted on such a vehicle has access to the exact information as conveyed by his superior and almost instantaneous updates if the situation changes. However, as the above quote from a recent sample Platoon Operation Order illustrates, the last frontier of the 21st century electronic battlefield is the foot soldier. Ground troops, dismounted soldiers, still rely on handwritten orders and paper maps, the same methods available to General Franks in Desert Storm, to Patton and Bradley in World Ward II, or for that matter, to Washington in a much earlier war.

Infantry tactics build on 5 principles one of which is that “Success depends upon all soldiers understanding what the platoon is trying to do and the specific steps necessary to accomplish the mission.”[4]

Problem Description

Original

This proposal addresses the need for commanders to brief dismounted soldiers on Operations Orders. Commanders have the benefit of viewing Operations Orders on embedded computer systems employed on vehicles but size and weight limitations do not provide for dismounted soldiers that are under the commander to view them. The increasing technology capabilities of Personal Digital Assistants (PDAs) would be ideally suited for downloading the commander’s view from the vehicle thus allowing him to brief his dismounted soldiers.

Today’s Army is increasingly waging information warfare. The effectiveness of a unit depends on all members having the exact information as conveyed by the commander, failure to do so may result in soldiers being in the wrong area at the wrong time with the danger of “fratricide” (injury or death caused by friendly fire) as a possible results. Operations Orders rely heavily on the premise of a picture is worth a thousand words. Maps are marked with standard symbols[5] to indicate friendly and enemy units, zones of fire, etc. As such, they are graphical with text to support.

In the past, a commander prepared operations orders by typing the text, locating a paper map of scale appropriate for the echelon the order are intended, and drawing the graphics derived from the text on a velum overlaid on the map. The commander would then brief subordinates using these 3 elements.

Today’s Army the commander types the text using a computer and stores it in a file for rapid distribution either using removable magnetic media or the Tactical Internet (TI), which is a wireless communication network. The commander is provided with digital raster maps and software tools to create the standard set of overlays, these, too, can be saved to file for rapid distribution. Militarized Personnel Computers (PCs) host the software that is employed to support these operations.

These PCs are embedded in numerous vehicle types that are used in various roles. The problem is space in vehicle is limited so briefing the dismounted soldiers is impossible. But with PDAs, this data can be downloaded to provide the commander with the capability to brief out of the confines of the vehicle. The following is a block diagram of the concept.

Description of the Program

Using existing software tools in embedded system, open a window to view map with overlays and another window to view the text. Develop interface to capture the image as bitmap, transfer this data to PDA. Develop software on PDA to receive the data, store the data to a memory card (if applicable), and display it. The display tool will also provide zoom and pan functions.

Requirements

  • Allow the commander when he has setup the embedded computer display with view of map with overlays, to capture the screen.
  • Capture the 800 by 600 pixel screen contents, convert to format for display on PDA, compress to reduce transfer time, and initiate transfer to PDA.
  • PDA client receives data and stores
  • Allow dismounted soldiers to view directories of save OPORDs
  • Allow dismounted soldiers to select OPORD map with overlay for display
  • Provide viewer for map with overlay that supports panning and zoom

1

[1] “Into The Storm – A Study in Command” by Tom Clancy with General Fred Franks Jr. page 147

[2] IBID.

[3] “Example Platoon OPORD”, Section 3.a -

[4] Headquarters Department of the Army Field Manual 7-8, 22 Apr 92, Infantry Rifle Platoon and Squad

[5] MIL-STD-2525B “Department of Defense Interface Standard - Common Warfighting Symbology”,

30 Jan 1999.