CMSI 401: Week Six

1 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

CMSI 401: Course

Documentation
Navigation
Home
Class Schedule

Class Notes
30, 2008

September

Course Docs
Coding Stds
Assignments

Architectural Design

Analysis
UML Notes
Bibliography
Acronyms

OK, so now you have a plan, you have the requirements,

you know what you are building and how you are going to
go about it process-wise (so your project planning is in
place). What's next?

LMU Main

HOW ABOUT THE DESIGN?!?

If you were building a house, the first thing you'd do at this
point is call an architect, to make a coherent plan for the
building. So, that's what you do here, too, only you are the
architect.
The first step in system architecture is to make one or more
diagrams of the system. This is similar to the requirements
process, in which you break the problem down into its parts.
This time, instead of figuring out the "what" you focus on the
"how", and instead of going "all the way to the bottom" of the
design, you only look at the major components. The goal of
this is to specify the system components and their
interrelationships. The design is done using both text and
graphics to provide a system block diagram. It is,
nevertheless, only a preliminary-level design. The document
should provide enough detail so that a new programming
team that did not participate in this preliminary design could
begin detailed design and coding. However, the
Architectural Design should not include any details of
implementation, such as variable names. For this reason,
even though the diagrams will be executed in UML, the
class diagrams will not need class fields or method names;
only the class names need to be shown in the block
diagrams. If you want to show the operations or processes,
UML use-case, sequence, or activity diagrams are a good
tool. If these are used it is not necessary to show the

23/06/2015 02:37 p. m.

CMSI 401: Week Six

2 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

message names or details of the data structures that you

imagine you will need. Remember that you must look at the
"big picture" (the house size and location) before you can
begin to worry about details (what material for the kitchen
countertops).

For example, if you have a GUI to control operations, you would draw a box labeled "GUI"
and write down any of the operations it would perform, inside its box. If the GUI had to
interface with another part of the system, you'd draw that as a separate box, and so on. The
idea is to convey what is commonly known as "an executive summary" to the reader.
Architectural design represents the structure of data and program components that you
need to build the system. A software engineer is usually capable of designing both the data
and the architecture of a system; in the case of large systems the architecture job is often
delegated to a specialist. That's because the architectural design of a software system is
one of the most critical aspects of a successful system. A good design generally takes
considerable foresight and a lot of trial and error. The architectural design is the first step
towards an implementation. The requirements specification has previously identified the
functions that the customer requires. The architectural design suggests an implementation
of those functions. This does not mean that the architectural design will simply be a module
for each of the functions described in the requirements specification. This is why both words
and diagrams are used. The diagrams show a graphic representation of the system parts,
and the text explains in a bit more detail what the intent is.

What the books say about it:

The architecture is not the operational software. Rather, it is a representation that enables
the software engineer to analyze the effectiveness of the design in meeting its
requirements, considers the alternatives at a stage when making design changes is still
relatively cheap, and reduces the risks associated with the implementation. Architecture is
important because:
Representations of software architecture are an enabler for communication between
all the parties to the development
The architecture highlights the early design decisions that have an effect on all the
software engineering work that follows
The architecture makes up a relatively small and understandable model of the system
structure and the interrelationships of its components
The two main parts of the architectural design process are the data design and the
architectural design. The data design converts data object which were defined as part of the
analysis model into data structures for the software architecture, and/or into database
architectures for the application to draw on. Data design focuses on representing data
structures that are directly accessed by the software. One set of principles, set out by
Wasserman in 1980, form a basis for a component-level data design approach that can be
integrated into both the analysis and design activities. It contains the following:
1. The systematic analysis principles applied to function and behavior should also be
applied to data.
2. All data structures and the operations to be performed on each should be identified

23/06/2015 02:37 p. m.

CMSI 401: Week Six

3 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

3. A mechanism for defining the content of each data object should be established and
used to define both data and the operations applied to it
4. Low-level data design decisions should be deferred until late in the design process
5. The representation of a data structure should be known only to those modules that
must make direct use of the data contained within the structure
6. A library of useful data structures and the operations that may be applied to them
should be developed
7. A software design and programming language should support the specification and
realization of abstract data types
The architectural design must put the software to be developed into context, meaning it
must define the external systems, users, and devices that the system must interact with,
along with the nature of those interactions. This is information that has already been
gathered, during the analysis and requirements phases of the project development. Once
the externals are described, the designers specify the structure of the system by definition
of the software components used to implement the derived architecture.
There are a number of ways to represent this architectural view, including UML (my
personal favorite), architectural templates, block diagrams, and architectural context
diagrams. An example of an overall architectural structure might use a UML component
diagram to define the parts and how they interrelate:

Remember, the intent of architectural design is to explain the system at a level of detail that
would allow a new team to step in and begin the detailed design, even if they hadn't been
part of the original development team. They should be able to determine from the
requirements document what the system is supposed to do, and from the architectural
design should be able to decipher the way the system will be structured. From that, they
could begin their own detailed design with a minimum of help from the original team. To do
this, you can use the existing ideas that you have already developed as part of the rest of
the design process.

Exercise For you to try in class:

23/06/2015 02:37 p. m.

CMSI 401: Week Six

4 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

Here is problem 8.10 from the Pressman book (see bibliography for citation). The
department of public works for a large city has decided to develop a web-based Pot Hole
Tracking and Repair System (PHTRS). A description follows:

Citizens can log onto a Web site and report the location and severity of
potholes. As potholes are reported they are logged within a "public works
department repair system" and are assigned an identifying number,
stored by street address, size (on a scale of 1 to 10), location (middle,
curb, &c.), district (determined from street address), and repair priority
(determined from the size of the pothole). Work order data are
associated with each pothole and include pothole location and size,
repair crew identifying number, number of people on a crew, equipment
assigned, hours applied to repair, hole status (work in progress, repaired,
temporary repair, not repaired), amount of filler material used, and cost of
repair (computed from hours applied, number of people, material, and
equipment used). Finally, a damage file is created to hold information
about reported damage due to the pothole and includes the citizen's
name, address, phone number, type of damage, dollar amount of
damage. PHTRS is a web-based system; all queries are to be made
interactively.

Develop a software architecture for the PHTRS.

Conceptual Design Review

When the architectural design is ready, frequently the customer will want to see what you
are proposing. This is the time for a "Conceptual" design review (CoDR). The intent of this
review is to present the customer with what you have accomplished so far, including the
completed documentation. However, the real meat of this review is the architectural design
that you have completed. It give the customer a "warm fuzzy" to know that the system
requirements are fully understood, that the design and development team is working well
together, and that the top-level system design is defined. Design reviews are also frequently
milestones on the schedule, and as such are often the source of revenue. Some types of
contracts specify payment on a per-milestone-completed basis, so that if the milestone is
reached on time the supplier gets a portion of the contract $$$$$. It is also customary to
add a bonus if the milestone is completed early, or a penalty if it is completed late (slipped
to the right).
Design reviews are a source of anxiety. The design team wants to make the best possible
impression on the customer. Everyone wants to present a "unified front" so that the effort
seems as if it is all on the same track. For a large project, there may even be a special
dedicated team just for producing/editing the presentation slides so that each department's
slides look like all the rest. Usually the people who are presenters rehearse their parts just

23/06/2015 02:37 p. m.

CMSI 401: Week Six

5 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

like it was a performance on a stage, which, in a way, it is. Even the people from the
customer's office who have been working with the supplier on the requirements and other
documents will get into the act. Often, depending on the importance of the contract to the
company, very high-level management may show up. All of this adds to the anxiety of the
process.
However, once the reviews start, if the first few presentations go well, everyone can settle
down a bit and begin to enjoy themselves. For medium and large projects, it is likely that
the customer will be treated to large quantities of free food in the form of breakfast, lunch,
and mid-afternoon sweets. Some of these things get really fancy with blintzes, scramble
eggs, or breakfast burritos; Chinese stir-fry, fajita wraps, or Caesar salads; and brownies
with macadamia nuts and white chocolate chips. Also, there is often a certain amount of
swag in the form of pens, notepads, presentation books, and sometimes posters, memorial
pins, or coffee mugs.
Actually, I like design reviews!

Preliminary Design Reviews

The Preliminary Design Review, or PDR as it is commonly known, happens when the
design has progressed far enough to show the Concept of Operations and the Process
Model views of the software system. The customer wants to see how the design is
progressing, and ask questions about all facets of the design. Where requirements
specification and the Conceptual design phase pay particular interest to the "what" of the
project, at this phase, the "how" is the primary focus, and this is usually reflected in
questions about the design. Some typical questions that come up are:
USER INTERFACE: What does the user interface look like? How does it work? Will
there be shortcut keys for the users, to speed operation?
SYSTEM PARTS: What are the main parts of the system? Is it a distributed or
monolithic architecture?
CONNECTIVITY: What networking methodology is used? Is it TCP/IP, RS232, RS422,
1553, GPIB, parallel?
DATA HANDLING: How does the system handle/store/retrieve data? Is there a
database involved? Will flat files be used? How is the file structure set up? How is file
security ensured?
COTS SOFTWARE: What COTS software is used? How will it be purchased? Where
are the companies that will provide it? Are they U.S. companies, or are they foreign?
How do they implement their security practices?
MODULARITY: How is re-use performed in the system? Are classes and packages
available to the entire system? Are there special handling requirements for this
implementation?
PARTS RE-USE: What parts of the system will be re-used?
H/W AND S/W REQUIREMENTS: How much memory will be needed? What other
hardware and software restrictions may be neeeded?
SCHEDULE: What is the development schedule?
TRAINING: How will users be trained? What type of on-line help is available?
VERSION CONTROL: How is version control implemented? What system will be

23/06/2015 02:37 p. m.

CMSI 401: Week Six

6 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

used? If it is controlled by another division of the company, how do we (the customer)

know they will support us after delivery?
SUPPORT: How will contractually required technical support will be provided?
VERIFICATION: How will the requirements specified in the requirements document be
proved correct? How are the test suites designed? What type of error handling will be
implemented?
Answering these (and other) questions is the focus of the PDR. It is not the intent to give
answers in all the gritty detail; in fact, it is not expected at this stage of the process to even
know or have planned out all the details to that granularity. However, the team should have
very good ideas about how things will work. PDR is the "top-level detailed design". This
means you must know not only the parts and their relationships, but also the details of the
relationships. You don't have to present all the relationship details to the customer yet, but
you should know what they are to planned to be. Thus, the focus of the review will be on
"what is planned in the design."
Of course, this means that the designed elements must be coherent, and must appear to
work well together. Otherwise the customers may have too many unanswered questions,
and they may come away from the design review without the "warm fuzzy" feeling that the
PDR is supposed to provide them. In some cases, there may even be a "pass/fail" grade
criteria applied, to which $$$$$$$ is attached. PDR is a schedule milestone, after all.
Where CoDR is focused at the top level, trade-study-ish level, the PDR is much more into
the details. For this reason, it usually takes longer. The PDR for my current project at work
lasted nearly a week. (It was actually scheduled to start at noon on Monday and be finished
just after noon on Friday. We got done early, and finished Thursday afternoon.) This is a
very large project, and has both hardware and software components, so it's to be expected
that it took this much time. However, depending on the amount of detail that is requested to
be covered, and the number and depth of questions the customer asks, even a relatively
simple project might take several days' worth of review.

Critical Design Reviews

For the Critical Design Review, even more detail is required. At this level, typically an
overview is provided that shows a condensed, "Reader's Digest" version of the CoDR and
PDR information. Then the details are presented. Many of the same questions asked at
PDR will be asked at CDR, but at a very exact level of detail:
USER INTERFACE:
How many GUI windows are there?
What are the buttons and other widgets on the windows?
What functions do they perform?
How do the shortcut keys and menu options work?
SYSTEM PARTS:
What are the classes and interfaces of the system?
What are the member data fields and methods (functions) of each class?
If it is a distributed system, what type of interprocess communication is used?
Are there shared data objects and how are they synchronized for proper data
access?
(The corresponding level of questions will be asked for monolithic architecture.)
CONNECTIVITY:

23/06/2015 02:37 p. m.

CMSI 401: Week Six

7 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

TCP/IP -- will this facilitate operation on a single platform? Are there any special
protocol definitions required? What is the definition of the standard IPC
messages?
RS232 -- will simple (9-wire) or complex (25-wire) serial interfacing be used?
What baud rate, parity, and number of stop bits? Will special COM-port or
Appletalk boards be needed, or will the standard ones be used? Who are the
suppliers? Are special drivers needed?
RS422 -- Same questions as RS232
1553 -- Will a 1553 Bus Analyzer and special software be needed? Is the system
going to act as bus controller, or will there be another device to handle this?
GPIB -- Will the number of devices controlled be within the 12-device limit? If not,
will multiple GPIB boards be used? How will bus arbitration be handled between
boards? How will device ID's be assigned?
Parallel -- How many devices will be required? How will this number of devices be
supported? Will an extension card cage be required to hold this number of
cards/port? Who is the supplier?
DATA HANDLING:
How does the system handle/store/retrieve data?
Is there a database involved?
Will flat files be used?
How is the file structure set up?
How is file security ensured?
COTS SOFTWARE:
What COTS software is used?
How will it be purchased?
Where are the companies that will provide it?
Are they U.S. companies, or are they foreign?
How do they implement their security practices?
SCHEDULE:
What are the details of the development and release schedule?
How do the milestones get broken down into tasks?
Is there a team to monitor progress or is a single person responsible?
What are the lower-level tasks in the schedule?
How much progress has been made so far?
What process is used for task status reporting?
What process is used if tasks begin to fall behind?
TRAINING:
Who is responsible for user training?
Do training courses cost extra and are there discounts for multiple attendees?
Will on-line help screens be windowing applications or browser-based?
VERSION CONTROL:
Will the selected version control system support the testing that is planned?
How will access security be implemented/maintained/enforced?
What is the process for performing updates?
What is the build process?
Are multiple versions supported?
Can these be simultaneous versions?
Can multiple development paths be handled?
What training is planned for replacement CM personnel?
SUPPORT:
Phone: Will technical support be available? What hours? How many different
users' problems can be assisted simultaneously?
On-line: Will on-line support be available? Is "chat" support available? Will e-mail

23/06/2015 02:37 p. m.

CMSI 401: Week Six

8 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

support be provided?
VERIFICATION:
What are the details of how the requirements specified in the requirements
document will be proved correct?
Will both positive and negative testing be performed?
How will results be logged?
How will result data be saved/controlled?
Will regression testing be facilitated?
How many tests will there be?
How many test suites will there be?
Are the test suites automated?
Do the tests require use of the same system that the system will execute on?
Each of these topics is covered in detail in the CDR presentation. These questions are
typical of the level of detail that is expected at CDR. Notice they address the same topics as
the PDR versions, but in a MUCH greater level of detail than their PDR counterparts. Also,
remember that this is a sample list, and is not really exhaustive.
One more thing to keep in mind about all types of design reviews is that they are done in a
presentation format. This means that the development team will become a team of
"presenters". The presenters are expected to talk in front of a room full of people, and to
present the information using some sort of slide-show format. They are also, by perception,
the "customer interface" to the design; as such, they are the first line respondents to any
customer questions. The customer is provided with copies of the presentation slides before
the actual meeting, so that they may review. In that way, the design review is much like the
peer review we had last week. However, this is a full-on presentation, not simply a question
and answer session. The customer will not come in and start off by asking questions. The
presenters will stand up and talk, and the customer may interrupt with questions during the
course of the presentation. Normally, there will be one or two presenters for each section of
the design. For example, there might be a presenter for the overall architecture portion, two
presenters for the GUI, two for the database, and one for the IPC messaging. The first
person might then provide a wrap-up.
. . . And yes, you will need suitable business attire, such as a coat and tie (men) or a dress
(women).

At Your Project Level...

For your project, you will have an Architectural Design Document seciotn in your SDF which
will be at the level of a PDR, and you will present the information at a PDR. Likewise, you
will have a Detailed Design Document section, which will be at the level of the CDR and will
be accompanied by a CDR presentation. Both presentations will be made during class time,
and the other CS professors will be invited. They will listen to your presentation and will
then be allowed to ask you questions. This exercise will provide you with experience giving
these technical design presentations to industry people and colleagues, and will also
provide you with input from people outside the project that will help you uncover problems
in the design that may show up later.
The Architectural Design Description of your delivery provides specific details of what your
project is supposed to accomplish. There are a number of ways to do this, but they all
involve both text and diagrams. Information includes system inputs, system outputs, and
23/06/2015 02:37 p. m.

CMSI 401: Week Six

9 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

system processing. This could be described in the text of the document around a diagram
that shows the blocks of what is in the system. Keep in mind that these things should be
defined fairly well at this point in the development process, so it isn't hard to come up with
the processing parts and show how things interrelate.
One of the best ways to show this is to use multiple diagrams for illustration purposes. For
example, consider a file-processing system that takes in a text file, extracts some specific
information from the text, formats the information into another file format, and outputs the
formatted data to another file. Here is a sample of what the ConOps description might be:

The system presents a window with two entry fields. A sample of the user
interface is provided in Figure 1 below. The operator types the source file
name into one field, and the destination file name into the other. The
system then opens the source file and reads the file data. The data is
searched to find the desired text to be extracted, and the extracted text is
put into an internal buffer. The source file is closed.
The processing is conceptualized in Figure 2 below.

Figure 1

Figure 2

Figure 3 shows the rest of the file extractor's operations. A new file is

23/06/2015 02:37 p. m.

CMSI 401: Week Six

10 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

opened as the destination, the extracted data is passed through the

formatter, then it is written to the new file in the expressed format, and
the destination file is closed. The operator is presented with a prompt for
a successful operation. If the operation fails for any reason, the operator
is presented with a dialog expressing an appropriate error message. If it
is possible, the operator is provided with an opportunity to retry the failed
operation.

Figure 3

The other part of your Architecture deliverable will be a User's Manual. This section is
intended to mimic what you are used to in a manual. There will be installation, operation,
and troubleshooting sections. The preliminary version will get the document started, so
does not need too many details, as long as the sections are there, and the basics of
operation is covered. Some ideas might be to cover:
How the server is started
How the screen appears when the server is active
How the client is started
How the client screen appears
Basic operation of the client screen controls
Description of the client screen appearance
Description of the shut-down process
Description of the scoring process
Installation of the game server and client
The Detailed Design Description of your delivery provides specific information about the
processing that is outlined in the Architectural document. There is already a fairly
comprehensive discussion of this on the Detailed Design Document course docs page.
There is already an example on that page, showing the expansion of a description from the
ConOps document into a CDR-level Process Model document view. This page uses UML
diagrams to show a use-case view and subsequent UML sequence diagram of a video
check-out in a video database system.
Here is a sample of what the Detailed description of the Architectural view above might be:

23/06/2015 02:37 p. m.

CMSI 401: Week Six

11 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

The system presents the operator with a window containing two labeled
entry fields and an "extract" button. A sample of the user interface is
provided in Figure 1 below. The operator types the source and
destination file names into the appropriate fields, then clicks the button.
The system searches for the source file at the location and name
specified; if the file is found, the system opens the source file and reads
the data. If the file is not found or an error occurs, the system notifies the
operator using another dialog window. The data is passed through a
comparator as it is read, whichi is used to find the desired text to be
extracted. Extracted text is put into an internal buffer. When the entire
source file has been read and processed, the source file is closed."
"The processing flow is shown in Figure 2 below.

Figure 1

Figure 2

Figure 2 also shows the rest of the file extractor's operations. The file

23/06/2015 02:37 p. m.

CMSI 401: Week Six

12 de 12

http://myweb.lmu.edu/bjohnson/cmsi401web1awk/week06-1.html

system is searched for any file with a name identical to the destination
name specified. If such a file is found, a dialog window is opened to notify
the operator and ask for further instructions. Older destination files may
be written over at operator discretion. If the operator has selected "overwrite", or if no file with identical name is found, a new file is opened as
the destination. The extracted data is passed through the formatter, then
it is written to the new file in the expressed format. When all the
formatted data has been written out with no errors the destination file is
closed. The operator is presented with a prompt for a successful
operation.
If the operation fails for any reason, the operator is presented with a
dialog window expressing an appropriate error message.
If it is possible, the operator is provided with an opportunity to retry the
failed operation in the event of an error."

This simple example would be followed by a set of more explicit UML diagrams for typical
use-cases. There should also be a diagram (for our example) of the data format which is
provided by the "formatter". Another diagram would show a sample list of the information
that is being searched for. If it were a combination of text strings in different orders requiring
extra processing during comparison, a separate drawing might be dedicated to the
"comparator" block. In this simple example, as you can tell, there is a host of information
which could be diagrammed and presented to the customer to show the details of the
design in their entirety.
As you can see in this example, there is a much-increased level of detail in the text, which
is accompanied by a correspondingly detailed diagram. Much of the text is the same in both
descriptions, but the detail level is much more specific in the Process Model, reflecting a
level appropriate for a CDR presentation.
As you put these documents together, think ahead to the Alpha, Beta, and Final
Presentations you will be doing. Try to estimate what a good level of detail would be for an
"executive" summary, as opposed to a "design review" presentation.

23/06/2015 02:37 p. m.