Chapter all pages all -- Modeling approach

(1) there is NO design phase. We just do some design in each iteration.

Exercise: List the UP Phases.

(2) "case" modelling -- if this is "use case" modelling -- this is a good start to an iteration.

(3) "Role modelling" -- never heard of it.

The best structural design is more likely to come from Larman's responsibillity assignment approach than anything else that I have seen -- "Best" meaning clear, reliable, Economical, Amendable, testable, and Elegant.

Chapter 1 pages 1-535 -- General

The precise UI code is determined by your platform. It may even be documented using a UML interaction diagram.

When I'm working on a design I abstract away from the platform to focus on the logic. Here is the scenario (I guess):

1. The user selects the menu and the system shows them a list of choices.
2. The user looks at the list and selects one.
3. The system does the selected action...

Translated into messages in a SSD:

Next step is to use GRASP to design the detailed interactions.... Exercise?

Chapter number pages ppp-ppp -- Final/ Grasp

Repetition and practice.

Chapter pages 221-270 -- Interaction/DCD

Doing too much in one diagram: Trying to put a whole scenario into one interaction diagram rather than the responses to each message in turn in separate diagrams.

Contrawise -- having to many DCDs...

How many Design Class Diagrams per Project

When you have more than 2o classes and the diagram is too big to fit on poster or board.... then you absolutely have to start packaging up the classes into logical groups and draw each package as separate diagrams + a package diagram showing the dependencies between the packages. We don't have much time to discuss this, this quarter.

But start to control the complexity by splitting the classes into layers: UI vs Domain vs Services.

Chapter 0 pages 0 -- dynamic binding

We mention this in CS202 and talk a lot about it in CS320 (Advert).

It is a long explanation.... but vital to understanding the Zen of Objects.

A binding is a conection between a symbol and a value. Computer programs are full of them. If they are computed by the compiler and/or linker then they are Static Bindings but if they can be changed as the program runs they are called Dynamic Bindings instead.

Example: When you declare a local variable

 	double x=5;

Life gets more interesting when you have objects and pointers to objects. The objects have a static type. But the pointer can point at objects of different types. And the type of object you point at, within limits, can be changed as the program runs. As a result the type of the object we point at is dynamic. The limit, with objects, is that a pointer can only point at objects that are derived from the type that is declared:

 		General * p; // General has a two derived special types: Special and SuperSpecial

 		p = new Special; // p refers to an object of type Special.

 		p = new SuperSpecial; // p refers to an object of type SuperSpecial.

Now, what happens if we write

 		p->something() ; // call the something() function

Answer: if "something" has static binding then you get "General::something()" but if it is dynamically bound, the running program can give you the General, Special, or the Superspecial version of function something().

Dynamic binding gives us polymorphism.

Chapter All pages ppp-ppp -- UML Notation

Turn to the inside back cover of the book.

Chapter 15,16 pages 221-270 -- Notation

We will review "arrows" (and lollipops) in an exercise today. for a summary of the notations.

Chapter 16 pages 242 -- Bloated Controllers

Yes. Lots. Indeed most programmers cheerfully put everything in a single controler class. This starts out OK, but as the program grows -- and all useful programs grow.....

As the bloated termite said when we left Noah's Ark: " I can't believe I ate the whole thing".

So.... I single function program, with simple data, and few external interfaces or data bases..... put it in a single controller.... and REFACTOR the momentthings get complicated. You are accumulating Technical Debt with each added function.

Chapter 16 pages 268 -- User-Defined Compartments

There isn't much you can say about what individuals and teams will do to add new compartments. Perhaps a list of responsibilities? perhaps a list of authors? .... Actually it is better to record authors as tags: {author=RJB, email=rjbotting@csusb.edu}. Similarly variations in meaning should be written as stereotypes.

SO my advice... don't add compartments.

Chapter 16 pages 269 -- Active Class

An active object has an independent thread of control or else it runs on a different central Processor. In other words it is doing it's own thing, and you send it messages which it may or may not ignore. Not elementary programming. Easiest in Java.... but tricky anyway.

Chapter 26 pages 471 -- GoF

(1) There are no "Grasp of Four"! Exercise -- what is the correct term?

(2) I have always found the "Protected Variations" GRASP extremely useful. For 40 years....

(3) These days I tend to work with computer languages, and these demand the Composite GoF pattern. In Java you will be using Singleton's all the time -- lots of "getInstance()".

(4) the half a dozen GoF in Larman are probably the most useful.

The GoF tend to pop up as a solution to a knotty design problem -- whether or not you use the UML or the UP.

Chapter 31 pages p. 519 -- Composite Aggregation

We discussed this in [ 11q.html ] and [ 18q,html ] , and it is complex and messy..... Exercise for the class to discuss.

How are quality scenarios related to the analysis of architectural artifacts?

2008 on Logical architecture and deployment

Are we going to review for the final?

In the last class I'll answer questions on every thing we've done. i

Chapter 30 pp all -- MVC

Can you give an example of MVC (model-view-control) with a different project? Not sure if I understand it correctly.

TBA

Chapter 34 pp 574 -- Three tier architecture

Is the three tier architecture what we call today MVC?

Yes -- the three tiers evolved from MVC and are a popular way to implement it.

Chapter 19 pp 559-586 + 651-654 -- Object Oriented Database

Object Oriented Database came up once before and once again in chapter 38. Can you give more details about this type of database.

Sorry, no. Not pat of this course and outside my knowledge.

Chapter 34 pp 561 -- UI objects

Why do SSDs illustrate the system operations, but hid the UI objects?

Because Larman says so!

Also because this is not a book about how to use the .XXX library of language YYY with OS ZZZ.

Chapter 34 pp 562 -- Coupling

What kind of coupling is noteworthy? The coupling diagram showed in our book is so messy,I don't think it can help me understand better.

Coupling is by definition messy -- and makes the software hard to understand. This is why we try to reduce it. In diagrams the arrows are warnings to the programmers to be careful.

TBA

Chapter 34 pp 559-577 -- Non-Layered Architectures

What would be some of the benefits of having a non-layered architecture? It seems to be more of a death trap than anything else.

Non-layered architecture is a booby trap. Good for a simple program. and hatches a disaster as the software grows to meet new technology and stake holder's needs.

Chapter 35 pp 559-586 -- Package

Can you give an example of how packages work?

How software is organized depends on the language. It also doesn't become critical until you have a large piece of software. So which bit of enormous code do you want to see, and in what language? I have a couple large systems written in C (not OO but well organized).

In C++ we use three techniques: split source code into files and use independent compilation, separate files into directories, finally, and new, we place different classes and functions in separate namespaces so that we can use the same names for different purposes.

In Java you use: files, directories (on the Internet), and the "package" declaration.

Idea: code that implements things in different packages should be placed so that it doesn't interfere.

Chapter 34 pp 559-586 -- Logical Architecture Refinement

When is it appropriate to use the refined logical architecture over a regular package diagram?

Large pieces of software.

Chapter 34 pp 570 -- Relaxed Layered Coupling

Can you explain in detail what Relaxed Layered Coupling is?

It just means that your upper layer classes can skip layers. I think it is harmless and common. What ever the theorists say.

Chapter 34 pp 559-577 -- Swing

On page 309 the books states that it assumes we are familiar with Swing. Chapter 34 talks about Swing. I am not familiar with Swing, can you elaborate?

Swing is just a collection of classes that helps a Java programmer define a user interface. You don't need to know about them for this class. The Wikipedia [ Java_Swing ] has a good general discussion.

In Chapter 34 actually hides the SWING library behind the ProcessSaleFrame class, or a couple of other similar classes.

Chapter 34.1 pp 564 -- Architecturally Significant Scenarios

Aren't architecturally significant scenarios like a detailed use case but drawn like Figure 34.4 on page 564?

That is no scenario, it is a sequence diagram.

Scenarios are lists of user actions. The figure shows one user action and a ton of internal message passing.

Chapter 34 pp 569 - 570 -- Using Observer

Message Could you go over the use of Observer in upward collaboration and what exactly is a PropertyListener?

I've just signed up to the UML discussions Google group. When messages are sent to this group I get Email telling me about them. Years ago I joined the Math-thinking mailing list. And so on. To do this you have to have your EMail address validated so that the mailer can send you the messages. Then the mail server adds you to a list of people who get the messages. It relies on me having a valid address. I rely on it to send me the data I want as it happens. I am an EMailListener, you might say. I am an observer of events by Email. I get the info but I am only loosely coupled to the rest of the group.

When we need information to flow in the opposite direction to the planned dependencies -- for example we want a value calculated in the domain layer to appear in a form/web page -- then we reduce the coupling by programming the upper objects/classes to listen in the lower levels -- using Observer.

This means that the listening class must declare its capacity to listen. This is done by implementing a particular list of functions -- a particular interface. So if there is a property Listener interface then a class becomes a Property Listener by implementing that interface. In C++

 	class ImAListener : public IPropertyListener { ... }

The compiler checks to see that the class fulfills its promise. The objects of the class can be sent messages about the property being listened for.

In the domain we keep a list of objects that are interested in the changes. All we need to know is that they implement IPropertyListener. We provide a couple of functions that add and remove IPropertyListeners from our list. When the property changes we send the message with the new data...

An object that implements IPropertyListener can add itself to the list and so receive notifications.

.Chapter 34 pp 576 -- Upward Communication On page 576, a UIFacade is added to the UI layer to add indirection to the GUI objects. Since it is not a part of the "physical" UI, it seems to me that it fits better as part of the domain layer--especially since one of its main purposes is to act as a controller for domain objects. What am I missing?

I think you've got it. This Facade -- like all Facades -- lies on the fault line between two packages. It could be put in either the package that it provides access to it or in the packages that use it. And now you see why we can't put it in with the "users" packages -- there may be more than one. Also a Facade is more heavily coupled to the package/system that it "protects" than its users. So we put it, in this case in the UI package. The Book says that a facade does not normally do its own work. Does that mean there are times when it does its own work?

I guess so.... but I don't like it. I think Facades should be thin.

Chapter 34 pp 571-575 -- Other Layer Pattern

Is the application layer optional?

Yes. Use when you have many controllers.

Chapter 34 pp 572-573 -- Fuzzy Set Membership in Different Layers

Different layers should be simple and understandable so why are fuzzy set terms used by different development teams?

Larman is using the term "Fuzzy Set" as a metaphor. He means that sometimes it may not be clear where a class belongs in the layers. In this case it is better to proceed as if it was in two packages than to freeze the project in a big row about the correct place.

Chapter 35 pp 580 -- Local caching

How important role does local caching play in NextGen requirements?

In computer science, local caching is a technique for making a program run faster by sing the principle of locality. For example keeping a local copy of recent data in a CPU. Another common example in an operating system is keep pages in RAM until they have to be copied to disk. Finally in a network we often maintain local copies of data on several nodes -- the Internet DNS system uses this to speed name servers.

Keeping a local copy of important data in a distributed system also improves reliability -- if the network goes down you still have the data.

I'd say that these principles apply to NextGen: local caching will improve reliability and speed -- given careful design.

It also makes a nice example for some GoF patterns.

Chapter 38 pp 653 -- Execution Environment Node and operating systems

Other than server software requirements (I.E. Widget server only runs on Windows server 2003) are there any other reasons the OS would be shown in its own box and not using {OS=*}?

No.

Chapter 35 pp 582 -- Packages

Why is it a good idea to reduce widespread dependences?

A widespread dependency means that a small change can have widespread consequences. Change this class and you'll have to fix bugs in a dozen other places for example.

Chapter 35 pp 582-583 -- Stability and Dependency

Message I see a lot of reduction of dependency, dependency on unstable packages and concrete packages. I also see a lot of examples of proper stable packages but could you show us an incorrect way to do figure 35.1, a how not to example?

TBA

Chapter 37 pp 37 -- Anything new after the last iteration

Is there anything new besides the diagrams and design patterns. Is there any artifacts that we didn't cover or should have?

As far as 2008 is concerned we stop after a quick look at deployment diagrams. We have skipped to useful techniques: state charts and activity diagrams. We will also not talk about UML components this year -- it may or may not be useful -- who knows.

I've also decided to cut out one artifact and ignore something that is rather deep and time consuming if done as recommended in this book -- architectural analysis. This is the discipline that analysis a system quality or non-functional requirement into a proposal for a design. Larman recommends using Technical Memoranda to record the reasons connecting a particular design decision to the stakeholder's requirement. We just don't have time for this. Also I have no evidence that the Technical Memoranda is used in Larman's form by large numbers of people. Finally -- I've yet to see a CS375 project where a technical memorandums is vital.

Chapter 0 pp 0 -- SQL

if one of our classes calls a SQL class, how do we represent this in our diagram?

There is no special way to show a data base in the UML.

It depends on the diagram and whether you are using it or implementing it.

If your software uses a preexisting library of classes for handling a SQL database then you can show in a class diagram if you like. You should show the data base as an actor (in a box) in a use case. You may show an object in the SQL class in an interaction diagram and add a comment. You could also name it like this

 		: SQL::classname

and use it to show how it is used. Another option (not one I've seen) is to show a "lost message" that leaves the calling objects and goes to a black dot.

If you are writing a class that uses SQL to access a database then you show the data base as n actor in a use case diagram. Put the SQL classes in a Technical Services package (keep things tidy!). Show the class in Design Class Diagrams and objects of that class in interaction diagrams.

Chapter 17 pp 475-500 -- state machines and the Web

does a web project have a state machine? since processes are only activated when a request to the server is sent.

Most experts in web design use a state machine to document the states a session can be in -- basically one state per page. Clicks and user actions are events that change the state. This is non-standard, optional, but helpful.

Chapter 19 pp ppp-ppp -- Code in diagrams

Is it a good idea to include notes on diagrams containing code? (i.e. page 367)

When the code says something useful/valuable. For example -- you have to explain to a team member a particular coding trick. Or, for example, you want to document how to use a class that you have invented or found in an existing library.

Chapter 31 pp 501-533 -- conceptual classes

This chapter focuses on conceptual classes as oppose to software classes. Will most of these classes become software classes?

I hope so. However, learning about the domain is itself a worthwhile activity, even if it turns out that some classes are not reflected in the software.

One reason why Larman in the UP delays Business or Domain Modeling is so that you choose the classes to model using the use cases. This means you are almost certainly going to use them in a DCD(Design Class Model).

Chapter 33 pp 542 -- Evolution Point

How difficult is it to incorporate evolution points as they arise?

Some changes can have a wide impact. Some effect only one method in one function in one class. The ideal architecture should let changes effect only small am mounts of code. However, usually, you don't know the ideal architecture until after the changes happen, so you work harder than you might want. Spotting an evolution point -- a hot spot for change early in the project can give you a more robust architecture that focuses change into small pieces of code.

Chapter 34 pp 559-568 -- Layers Pattern

Dr. Botting can you give a clear explanation of Facade and Facade Pattern? please.

You need to use some classes -- example to help your software access a data base. You hide the complications of doing this inside classes that you write. The classes you write provide a simpler way to access the data base. The rest of the program uses the simpler functions.

The simpler classes are called a Facade -- the curtain that hides the details.

Consequence: technical details of the data base are separated from the problems of the domain. This is good.

In this case the Facade would be put in a Technical Services layer.

You can put a Facade around any complex subsystem in your software. It is an example of using GRASP "Indirection". Such Facades belong in other layers.

Chapter 34 pp 563-4 -- Architecturally significant scenarios

In an inter-layer and/or inter-package interaction scenario what determines an architecturally significant scenarios.

I guess experience counts! You don't need this knowledge for this class.

A scenario is significant if it forces a particular structure. So you look for scenarios that involve classes in many layers. You want to explore requirements that lead to calls to functions in classes from the user interface level down to technical services.

Chapter 34 pp 365 -- Packages vs Subsystem

Can you explain in better detail the difference between simple packages and subsystems?

Not really -- and it is not two important for this class.

But when you have a set of classes that all use each other and are all about the same thing, and their objects have lots of interactions... then this is a subsystem rather a package. It is a matter of coherence. How closely are things stuck together by the solutions that they encode.

Chapter 34 pp 564 -- Package Diagrams just in time for the 455 final

So when we use a package diagram do we also need a counterpart IE, interaction diagram and where does the deployment diagram fit in?

Personally I'd only show interactions between packages when you have an audience who are likely to be unable to see what the dependency arrows mean.

Deployment is for explaining the hardware and software you are using. Only needed if you are doing something out of the normal box.

Chapter 34 pp 571 -- Layer Pattern issues

in what situations is logical views of architecture more convenient to use than Process and Deployment views of architecture?

It is not a matter of convenience. Mostly you will need both: deployment defines your platform and the logical architecture the structure of you software.

However, if there is only one program running on a plain vanilla PC then the deployment diagram is almost worthless. And if the program only has 2 or 3 classes then packaging them doesn't seem worthwhile either.

Chapter 34.3 pp 573 -- layers

How can layers affect performance?

It takes time to call a function. Suppose we have 26 packages called A, B, C, ... Z. If A::a() calls B::b() that calls

1. C::c() that calls.... Z::z() then you have 26 function calls. However
2. if A::a() just calls Z::z() directly it only takes 1 function call. This is 26 times faster.

   As a rule -- don't worry about this unless tests show that the software performs badly. Much time has been wasted by programmer doing "premature optimization" -- improving the speed of parts of the software that don't effect the whole.

   Chapter 34 pp 576 -- Logical Architecture Refinement

   What is polling?

   This is a technique that was originally used in hardware. One part of a system needs to know when some event happens. So it repeatedly asks "Has it happened yet?".

   Think of a child on a road trip: "Are we there yet?"

   Chapter 34 pp 576 -- Model View & Upward Communication

   can you go into more detail about "pull-from-above" or "polling" and "push-from-below"? I am unclear on their uses and purpose.

   Software is easier to develop and maintain if it is organized so that the dependencies don't form cycles: A::a() calls B::b()

3. which calls C::c() which calls A::a2(), for example. Now we should place A above B and B above C because that is the direction of calling -- but C also calls A -- this is therefore push from below.

   One solution is to refactor... for example does a2() really belong in A or should it be moved to package C? This can move hole classes from one package to another! For example you might start a design with an SMTP server in the User Interface layer because is is an actor in the use case. But the logical architecture starts to look messy so you move the SMTP handling classes done into the Technical Service layer. The design becomes a lot cleaner.

   Another solution is to create a low level interface for A (call it I)

4. that contain I::a2(). Then make A::a2() implements I::a2() and
5. C::c() calls I::a2(). The interfaces decouples the two packages.
6. A neat variation is for A::a to pass a an object callback that
7. implements the interface I::a2() down to C -- and C::c() calls it to signal the event.

   However, you can sometime reverse the direction of call. Suppose

8. that C::c() calls A::a2() to tell A that something has happened or to pass A some data that it needs. Instead we can write a function
9. in A that calls a function C::c2() that gets the data from C ( pulling from above ) or finds out if the event has happened ( polling ).

   Chapter 38 pp 627 -- Framework

   What are other examples of frameworks besides the Java's Swing framework

   Microsoft .NET has some... I found a couple of dozen at [ Framework ] on the Wikipedia.

   Symptom: interfaces and abstract classes -- you have to supply the functions that the framework names. The framework supplies some functions and you provide others.

   Chapter 38 pp 651-654 -- UML Deployment and Component Diagrams

   I am unsure on when to use the 3D box and when to use the 2D box that we have been using, and also what it would mean to switch to two.

   Some cases are simple: hardware is 3D, your code is 2D. Example the users PC.

   Similarly any piece of software that interprets code is 3D. Example the server's OS and the user's JVM.

   If it is not hardware and it doesn't interpret, run, or execute code it is an artifact -- 2D.

   Chapter 38 pp 652 -- Deployment diagram

   In a deployment diagram, can a device node ever appear inside an execution environment node?

   I can't see how! This would imply that a piece of software is interpreting some hardware! Normally it is the other way round.

   The norm is: hardware executes software.

   However -- an execution environment can communicate with hardware -- but that means the device is OUTSIDE the execution environment box.

   Chapter 38 pp 651-653 -- Deployment vs.Component diagram

   What makes a Deployment diagram different from a Component diagram?

   A component diagram shows how software components are connected. A Deployment diagram shows how hardware components are connected (and some software).

   Components have a special icon in their top left hand corner and use a lot of lollipop connectors.

   YAGNI in the final.

   Chapter 39 pp 656 -- Software Architect document

   How much detail can, or should go into The software Architect documentation?

   Enough detail to explain the problem or concern and to make it clear why your proposed solution is a good way to do it. Not in the final.

   Chapter 39 pp 651-660 -- Documenting Architecture -- SAD

   Why is it important to create a SAD.

   I'll never forget a graduate student in England who was working at the Rutherford labs.... "What I really need is this programmers waste paper basket!".

   You need to document why you chose a particular solution, and why you rejected other solutions.

   The document also improves the chances of getting a better solution.

   To be brutal: every problem has a obvious solution that just doesn't work. The SAD forces you to sweat the details and get a solution that will work.

. . . . . . . . . ( end of section Questions and answers on logical architecture and deployment) <<Contents | End>>

Questions on Architecture

Ch 33 pp All : Architecture

Is there ANY WAY to avoid using packages? I don't like them!

The only alternative is to keep every program you write small: no more 200 lines and no more than a dozen classes.

That way you end up with a thousand programs and problems with how they interact.

Packages are like tectonic plates. They allow a certain amount of sliding and shifting but you hope that there won't be any big shifts.

Ch 34 pp 541-558 : Architecture

A lot of this looks the same as the logical architecture we've done in our first iteration. Is this more of a reminder to make sure our previous architecture diagrams are up to date? Further, how should the architecture in this iteration differ from the previous iterations architecture?

Yes: this is a review.

In theory (and I hope in your future practice) logical architecture should be pretty stable after the first two iterations because you should use the first few iterations to test it out.

Architecture changes when some thing unexpected happens: a new wide ranging requirement: example -- no SSNs will be used any more. The other tectonic event: change of hardware or platform.

Ch 33 pp 542-550 : Architectural Analysis

In this chapter the author says that non-functional requirements are given thorough attention more than the functional ones. Why would this be the case?

Basically Larman has put of the tough part until now. This is the chapter where most of the advice on architectural design is discussed. And architectural design is about special non-functional requirements. The rest of the book is about meeting functional requirements. In those parts of the book the only non-functional requirement is implicit: trying to preserve the programmer's sanity.

Ch 33 pp 554-555 : Separation of concerns

Are there other techniques we can use in order to achieve a separation of concerns?

The term comes from accounting.

Discussion: how many different ways can you think of for making sure that two different requirements or design decisions don't end up in the same piece of code? (Check the patterns and principles I've listed on this site).

Ch 34 pp 564 : Interaction & Packages

When should interaction diagrams denote package information? Would not class diagrams be a better location for communicating 'cross boundary connections' between packages?

This is right: use packages to keep complexity under control and use a package diagram to show what you're doing.

But once a class is put in a package then its name in other diagrams changes. If you omit the package names from interaction diagrams you don't know where to find the classes -- who said the names were different? Each package is a namespace.

Ch 34 pp 570-571 : Layer Patterns

Please explain "layer patterns" in greater detail and give some examples of how to apply them?

Over the last 5 years people have learned that it pays to put certain types of classes into a "layer". Layers separate classes that shouldn't get muddled up with each other. For example all the classes that are inspired by the domain model form a "layer". All the classes/code describing the "look-and-feel" of the user interface form another famous layer -- and every body agrees we don't want to muddle up the user interface with the "model". Another classic layer: persistence. These classes handle the data base (and/or files) that preserve data between runs of programs. Again it makes life simple if the domain does not have to worry about the kind of data storage you are using and vice versa. The book has an excellent picture of the classic architecture: Use it.

. . . . . . . . . ( end of section Previous) <<Contents | End>>