ACS 2913 Software Requirements Analysis and Design

Document Sample
ACS 2913 Software Requirements Analysis and Design Powered By Docstoc
					           ACS 2913 Software Requirements Analysis and Design

                                  LECTURE OUTLINE 9
                                   prepared by E. Kaluzniacky

Cancel an Order use case
p. 437- 9

After the handed out use case Look up item availability, we study the use case
Cancel an Order from the text

p. 437 and 438 give us the first-cut DCD (2) and the SSD (1). We then get
started as on p. 438, bot.(3) Our first-cut detailed sequence diagram (4)) is
shown on p. 439. The design with data access objects is on p. 449 (5) and the
additions to this due to view classes are on p. 453 (6).

Study these on your own, in detail. You will redraw these (modified) in asgt 3

On p. 449 note: the domain object is in front of its DA.object and then sends a
message to the domain object (backwards). The Create methods can each have
a identifier (pointer) that they are assigning in the message e.g.,
anOrd:=createOrd (as on p. 443). Also note the Save() messages from the
domain object to its DA and eventually to its table in the relational database.

Note that a find message is sent to each DA object because it has a find method
to respond (see p. 514 on DA objects).

Know these two patterns, i.e., the one handed out and the one on p. 449 / 453.

Data Access Objects

First, read top, p. 447.Then, flip to p. 514. Understand this. How SQL is involved
in a DA object. However, we have been sending Save messages to the DAs in
449 and this DA has no Save method (this is a flaw in the text).

The diagram shows the interaction between objects of the ProductItem domain
class and the ProductItemDA class.

The data access class has methods that add, update, find and delete fields and
rows in the table or tables that represent the class. Usually they are written in a
language such as C++ or Java and embedded SQL commands.

The object instances in a fully OO system operate in memory; but an instance
gets its methods from the class and its data (attributes) from the relational data

There are also purely “Object oriented databases”, but the relational dbms
predominate in today’s IT world.

Updating the Design Class Diagram

p. 457

Now that we have the methods identified in the sequence diagram, we need to
attach the methods to the object classes, thus completing our DCD, at least the
domain part of it (which we have so far on p. 438)

The methods needed can be:

                     Constructor methods
                     Data get and set methods
                     Use case specific methods

It is optional to include constructors and get/set methods in the final DCD, but it
may be good to do this at a beginning stage

Note: when a message is sent to an object, it must be prepared to accept that
message and initiate some activity. Thus every message that appears in the
sequence diagram requires a method in the DESTINATION object

We go though every sequence diagram and find the messages sent to a
particular class. Each message indicates a method

See the format for a signature on p. 411. Note the type expression is the type of
the return parameter from the method

On page mid p. 457, we see an explanation of how the methods are assigned to
the InventoryItem object class based on detailed sequence diagrams.

The final DCD for the domain level object classes including the Controller is on
page 458.

Now, each method signature whose logic is not immediately obvious must now
be expanded upon in some other diagram, not specified by UML. This could be a
program flowchart, pseudocode etc.

Package diagrams

A UML package diagram shows associations of related classes.

Package notation is a tabbed rectangle. The package name is on the tab.
Classes are placed inside the appropriate package based on the layer to which
they belong (e.g., view layer, domain layer, data access layer).

To develop the package diagram, we simply extend the information from DCDs
and detailed sequence diagrams. See p. 459

Dotted arrows show dependencies They show dependency relationships. A
dependency can be between packages or between classes within packages. The
arrow points from package that is dependent to the one that is independent.

Dependency means if there is a change in the independent element then the
dependent element may also have to be changed.

e.g. if a change is made in the Order Class, then the OrderWindow class may
have to be changed

On page 459 , ProductQueryForm depends on Catalog (one class on another);
also, the view layer and domain layer are dependent on the data access layer
(one package on another). A change is the data structures may usually require
changes in the domain and view layers.

Package diagrams can also be nested. Subsystems can be denoted with
package diagrams. Read middle p. 460; See p. 461.

Different packages can be assigned to different teams of programmers;
dependency arrows will indicate where communication among teams must occur.

Package diagrams are used to show related components and dependencies.

Communication diagrams
p. 454

before, they were called Collaboration Diagrams

   -   this is another kind of interaction diagram which can be used for
       determining messages between objects in a system

Know Fig 12-20 on p. 455 well: actor, link, object, message

Note the syntax of a message descriptor:

   -     each message is numbered sequentially

   -     note how messages are numbered on p. 456

the focus of a communication diagram is on the objects themselves, but it is
more difficult to visualize the sequence of the messages; see bot. p. 456

Implementation issues

p. 461

We do not want to couple view layer, domain layer and data access layer classes
too closely. Objects in each type of class should be responsible for only specific
p. 462:
View layer classes should have logic for:

Domain layer classes should have logic for:

Data access classes should have logic for:

Software design PATTERNS

See p. 463

A pattern is a “specific way of handing particular kinds of problems” in terms of
how objects are set up and how they send the messages to each other.

Different applied domain situations are similar enough from each other to benefit
from accepted and tested ways of handling such situations. Patterns embody
good design principles. Some patterns are very specific and others are more
general, referring to approaches such as “using a controller”.

Design patterns became a widely accepted OO software design technique. You
will study typical design patterns in ACS 3913.

Read about the GoF patterns, for general knowledge. We may casually examine
a few of those in the text.



Shared By: