CSSE 497 : Architecture Review

1
CSSE 497 Architecture Review
Below Leaning Tower of Pisa actually looks
halfway ok from this angle. From
www.dankarran.com/photography/italy/pisa/pisa01/ .

• Rose-Hulman Institute of Technology
• Steve Chenoweth
• 13.October.2008

2
Other - Upcoming req reviews

• Well have requirements reviews during your
  regular weekly meeting, in week 7.
• We will send out the list of people who will be
  there.
• 3 days ahead of time, email a copy of your
  problem statement and the requirements to all the
  review participants. Only the requirements will
  be reviewed.
• Use the action item templates as a reviewer.
• Use the checklist for reviewing
• ? Questions on this?

3
Other - How should your test plan look?

• For now, preliminary, as follows
• How youll test the requirements a list of
  black box Acceptance test areas (which later
  will become sets of test cases)
• How youll test the architecture additional
  white box System testing areas (which also
  become test cases)
• Use the Validation Test Plan template, in the
  testing examples on the course website, but keep
  test case descriptions general
• What would you test? and
• What should the results be?

4
Other - How should the configuration mgmt plan
look?

• Part of your project plan.
• How will your code and documents be managed?
• How you will gather, classify and decide whats
  accepted. Examples
• Source code management
• Baselining your documents
• Look at example under Maintenance (on senior
  project website here).

5
Other - How should the risk assessment look?

• Also part of your project plan.
• Initial content (as recommended last year in
  CSSE375)
• Minimum of 4 risks, each detailing a mitigation
  strategy.
• Minimum of 1 opportunity.
• Quad chart

• All risks/opportunities should be in the "If
  ________, then ________" format.
• Quad charts should be similar to the image at
  right, but containing the number of risks in each
  box.

• Mitigation strategies should contain the actions
  necessary by which project resource (team member)
  to avoid the risk or realize the opportunity.
  Mitigation strategies should also contain the
  time frame for revisiting the risk/opportunity
  and deciding on an alternate path.

6
How to start your projects development

• The strategy is a combination of top down and
  bottom up
• Top down start the architecture (next slide)
• Bottom up
• Do prototyping Two kinds you should consider
  now
• Human interface so the client (and users) can
  critique
• Whatevers hard to do like interfaces to other
  systems, or answering quality attribute
  questions!Note Both kinds are probably throw
  aways!
• Start working with pieces that have to fit like
  the database, C .Net, the clients existing
  systems, etc.

7
The top-down design is your systems
architecture

• Were talking about
• a high-level design
• tied to your problem statement
• which ends up as an extensible coding
  framework,
• along with a document to guide further design.

8
Why bother with architecture?

• Xtreme programming suggests you dont have to
• People who get by without an arch usually are
  doing one of these
• Simple systems (e.g., a few thousand lines of
  code, tops), or
• Systems of a style they know really well (and so
  intuitively do the architecture), or
• Systems for which something else handles
  architectural decisions, like the database

9
Then what does spending time on the architecture
do for you?

• Strategically solves the quality attribute
  problems like making it secure or testable.
• Gives conceptual coherency to your system,
  enabling it to last beyond Rel. 1.0.
• Proves to your client and others1 that your
  basic design ideas are sound.
• Gives a big picture of the whole development,
  driving your plan process.
• Lets multiple team members contribute detailed
  design implementation in a consistent way.

1Yourselves, instructors, later maintainers, and
other stakeholders.
10
how to do your projects architecture

• Look at other systems which are like yours.
  How are they designed?
• What design do the bottom-up pieces require?
• Keep the problem statement on your desk Your
  high-level design has to solve that problem.
• What style should your design be? (see next
  slide)

11
Whats an architectural style?

• See Garlan Shaws famous article1 for an
  introduction / refresher on this subject.
• You may use more than one such style for
  different things the system does.
• Lets look at a few examples

12
Arch style Pipes filters

• Used to move data through a sequence of steps.
• Often, some filters are 3rd party.
• This could be how you convert data for your
  system.

13
Arch style Layered system

• Often your system sits on top of lower level
  pieces (e.g., the MySQL and PHP).
• Each layer only talks to the one above and below.

14
Arch style - Interpreter

• Now youre glad you had 304!
• But this is also the kind of thing to be careful
  about Do you really have to do this to solve
  their problem?

15
How to make it architecture

• It should be a high-level framework that makes
  it easy to add more code under it... and test
  that code!
• Anticipate what will be in the whole thing
• Make it just general enough for all that!
• What decisions will be made when? (E.g., at
  design time versus at run time)?
• Whos going to be doing what follow-up steps?
• Some examples of framework type code
• Parent classes
• Interfaces defined (internal and external)
• Examples of methods you can later overload
• Iterators generics other Gang of four
  patterns
• Think Ballworlds from CSSE 120
• Getting it right the first time tough! Which
  is why you you do this early.
• What youre building in code is a
  development-time view, but
• What has to work, mostly, is a run-time view.

16
Answering the problem statement (and the
supplementary spec)

• Look for constraints there like what else the
  system must run with, or how it will be
  administered.
• Quality attributes Use Basss list and any
  others key to your system supplementary spec
  should have scenarios for these
• Usability
• Availability
• Performance
• Modifiability
• Security
• Testability one goal here should be to make
  everything testable with the whole system as soon
  as its coded (as in Xtreme programming)
• So, what strategies does your architecture use to
  achieve these?

17
Validating the arch vs req

• Use cases you should be able to step through
  the main ones of these and visualize how code
  will run under your framework to accomplish them.
• This lets you see how it will run,
• And picture the additional code that will need to
  be added for that.
• You wont be able to answer everything in the
  requirements this is high level!

18
How to document it

• Write this as youre building the actual
  framework, alternating as to which is the guide
  for which
• Make it clear what a figure does
• Design time - UML Class diagrams other figures
• Run time Component connector, allocation
  views
• A strategic question can members of the team
  now design code test independently, using
  this as a guide?
• Lets look at the arch template on your senior
  project course web site

19
What do the component and connector views look
like?

• They show how the software actually works.
• Heres one from the SEI paper cited in the arch
  template

20
How detailed should the design be in the
architecture document?

• Theres a conundrum
• The document should be high-level for
  explaining the design, but it needs to at least
  point to details of
• The frameworks interfaces and features, for
  those wholl use them, and
• How the framework itself is built, for
  maintaining that.

21
So,

• Almost immediately youre faced with also
  detailing those interfaces, high-level code in
  the framework, etc.
• Either
• Add that to the architecture doc, or
• Make this the start of the following design doc
  with pointers from this one to that one.

22
What else will be in the detailed design?

• Detailed versions of the use cases, showing how
  each one is implemented
• User interface pictures (like screen shots from
  the GUI prototype)
• Details of quality attribute scenarios (from the
  supplementary spec)
• Detailed UML class diagrams
• Detailed UML component-and-connector diagrams,
  showing internal external interface
  descriptions
• Pseudocode of the key algorithms
• Strategies for white-box testing
• Data definitions and ER diagrams
• ? This will be a major deliverable in the winter
  term!

23
Examples(at least of the views)
Question What viewtype is this?
24
Examples
25
Examples
26
Examples
27
Examples
28
A few last thoughts

• Arch evolves into being the design /
  implementation.
• Test plans should go with the high level design.
• Arch doc usually stays separate. If it becomes
  the design document, then you should keep the
  high-level stuff clear.
• We should be able to line up the problem
  statement and the arch document, and see how
  youre going to solve the problem.

29
Questions?
How will your arch look?