Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

• CSci 375/02 Introduction to Process and Book
• 1.2 pp 6 -- OOA/D Skills
• 1.2 pp 6 -- Nine fundamental principles
• 1 page 11 Forward and reverse engineering
• Section 1.5 A Short Example pages 8-11 -- The Dice Game
• Warning about the example 1.5
• 2 page 13 3 perspectives
• 1 pp 12-13 -- perspective
• 1 pp 13 -- Specification vs implementation perspective
• 2 page 13 expressing the logic of the program
• 1 pp 3-16 -- OOD: Principles and Patterns
• Domain Model vs Design Class Diagram
• The Cake Image of Agile Development
• Example of an iterative Process -- the FRiendly EDitor(FRED) project.
• 2 page 16 Early testing
• Unified Process phases and disciplines for this class
• 1 page 17 Domain Models
• 2 page 18 Length of an iteration
• 2 page 23 Waterfall process
• 2 page 23 waterfall polluting agile process
• Alternatives to UML
• 2 page 28 which requirements to do first
• Waterfall
• 2 pp 18 -- unified process vs. rational unified process
• The Rational Unified Process phases and Disciplines
• 2 Pages 18-19 Model or framework
• Next
• Project Kickoff
• Review Questions
• Standard Definitions

CSci 375/02 Introduction to Process and Book


Table

Date	#	Topic (Participation 2pt)	Study pages (2 pts)	Quiz(15 pts)	Project Work(10 pts)
Previous	1	Surviving CSci375	Mock Q0	-
Today	2	Introduction	vii-40	Mock W0	-
Next	3	Inception	41-59	Q1(1-59)	W0 due


(Close Table)

(Input): Introduction to the process and methods of the text.
Table

Pages	Subject	Notes
vii	Contents at a glance	A good starting point.
ix	Contents by topic	Return here to review a topic
xi-xviii	Contents	Don't Panic(Chapters are small)
xix-xx	Forward	by Kruchten
xxi-xxv	Preface	Why, What, How, Who, Etc.
3-16	**** Object-Oriented Analysis and Design OOAD	Important (dice)
17-40	** Process: iterative, Evolutionary, and Agile	Important


(Close Table)


1.2 pp 6 -- OOA/D Skills

In chapter one it discusses how a critical ability in OO development is to skillfully assign responsibilities to software objects because it influences robustness, maintainability, and reusability. This sounds a little subjective to me because one developer may think differently than another when it comes to assigning the object. How do you know if the responsibility is properly assign to the object?

The main purpose of the book is teach you this skill. It is not easy. It is a bit subjective, at first. But, it can be learned... You should find that, at the end of the class, that it is quite rational and explainable: we assigned the responsibility for zarking widgets to the Widget class because Widgets are the Experts.

1.2 pp 6 -- Nine fundamental principles

In chapter 1.2 the author points out that there are "nine fundamentals principles in object design and responsibility assignment are presented and applied." What are those nine fundamentals principles?

They are listed opposite the inside of the front cover of the book... and in my notes on the WWW. Look for "GRASP".

1 page 11 Forward and reverse engineering

What does the author mean by "forward engineering?"

It proceeds from analysis to design to implementation -- with no feed back.

Opposite of looking at code to figure what is going on in the designer's and analysts' minds: reverse engineering.

Section 1.5 A Short Example pages 8-11 -- The Dice Game

Notice the steps and diagrams used in this example. Do not forget them. They will be part of your project, furute classes, quizzes, and the final.
1. Steps::=following,
   
   1. Define use cases
   2. Define domain model
   3. Define interaction diagrams
   4. Define design class diagram -- -- --(DCD)
      
   
   

   An iteration is not complete until we have coded and tested our analysis and design. So I have taken the daigrams on page 10 and coded them in C++. Study: [ DiceGame.cpp ] and [ Die.cpp ] to see the C++ code that I developed.

   I also used a pair of unit tests [ testDiceGame.cpp ] and [ testDie.cpp ] in C++. You should compare the code I produced with the diagrams and text in the book. By the way, in the process of coding and testing this rough design I found a couple of methods that the book does not mention but are implicit in the use case description on page 8 -- the user needs a way to find out the score and also to see if they have won. It helps to show all the data flows using a System Sequence Diagram like this

   

   which needs a more complex DiceGame class:

   

   Warning about the example 1.5

   In practice we do not "define ALL the use cases" before we start the defining the domain model. Instead we should focus on only a few use case, a partial domain model, some of the interactions, and so add to the design and code. We eat the elephant, one bite at a time.

   2 page 13 3 perspectives

   Can you clarify the differences in the meaning of Class in the three perspectives listed in this chapter.

   
   

   Conceptual -- describes objects that are outside the computer + ideas in the stakeholders heads. Concepts not code. Specification -- Describes the kinds of objects we expect to need to make the software work and the relationships between them. Implementation -- Blueprint for code. Or a reverse engineered diagram of the actual code.
   
   

   1 pp 12-13 -- perspective

   There are 3 perspectives; Conceptual, Specification, Implementation. Do you need to use all of them or can you just use one of them when doing a project?

   Expect and plan to use all 3. You'll be using conceptual models most at the start (with a few specs and implementations).... and by the transition phase it'll be all Implementation.

   The good news is that many of the things you draw in a conceptual model can be copied into Specifications and Implementations.

   1 pp 13 -- Specification vs implementation perspective

2. There is one example in the book for both Specification and Implementation Perspective. What is the obvious difference between the two that would make specification perspective seldom used and most software-oriented UML diagramming assume an implementation perspective?

   Programmers really hate thinking about the real world and hate writing (and reading) specifications. They seem to love the code, the whole code, and nothing but the code??

   There is a similar bias with most methodologists:-(

   2 page 13 expressing the logic of the program

   In the software implementation for the dice example, how is the logic of the program depicted within the UML programming language? Or, it is just an abstraction of the software components?

   In this book and course interaction diagrams will be used to express the logic. UML2 sequence diagrams have enough features to express most any logic you could want: iteration, selection, sequence, functions, arithmetic, etc....

   When one needs to express a complex algorithm in the UML we use Activity diagrams. But these will not be required in this course.

   1 pp 3-16 -- OOD: Principles and Patterns

   Please explain the concept of patterns in more detail.

   A pattern is a way to solve a class of problems. It resolves the conflicting forces well enough for it to be useful. It should also work well with other patterns to form a "Pattern Language".

   The history starts with a set of patterns for architecture: rooms, buildings, towns, ... by Christophe Alexander (circa 1979). One of his patterns:

   ---

   When adults enter a room they often need to put something down or pick it up.

   Children like to hid under things...

   Therefore,

   1. Put a shelf around a room just above the height of a child and just below the hand of an adult.

   ---

   For more checkout my website. [ patterns.html ]

   Domain Model vs Design Class Diagram

3. +++ The classes in a Domain model are sets of similar real objects
4. +++ The system is not not yet real and so is NOT in the domain model. (Don't panic -- it appears soon enough, some where else).
5. +++ Domain classes don't have operations/functions. Real objects don't work like objects in software.
6. ++ Most design classes are inspired by doamin classes.
7. ++ Design class diagrams may have extra classes in them that are needed for technical reasons. They aree not real objects, so they are not put in a domain model.
8. +++ A design class Diagram is derived from a set of interactions.

   The Cake Image of Agile Development

   Perhaps some images may help. If I offered you a cake to eat...

   

   Would you plan to eat it one layer at a time: requirements, Design, Code and then all the tests: [ cake2fragile.png ] or in slices: [ cake2agile.png ] with a little bit of each layer and a test on top?

   In this class I will covering a particularly flexible process for taking one slice at a time.

   Example of an iterative Process -- the FRiendly EDitor(FRED) project.

   I implemented a Friendle Editor for my students in 10 weeks in the fall of 1982, while bootstrapping the CSci dept, using a language I was not familiar (BASIC) with, on a completely strange operating system (RSTS).

   This was only possible because I started with a nearly empty program and grew it one feature at a time.

   2 page 16 Early testing

   "Activities such as load testing will prove if the partial design and implementation are on the right path." This seems to occur at a relatively early phase in the design process. Is an early prototype of the program created for users to test the program this early, or is this merely an invitation for users and stakeholders to witness the iterative development on paper (namely observation of the UML diagrams and Pseudocode)?

   It should be a real, high quality, incomplete implementation that tests out the feasibility of the approach.

   Sadly in this class we won't get to this.

   Unified Process phases and disciplines for this class

   
   Table

   Discipline	Inception	Elaboration	Construction	Transition
   Business Modeling	**	**	-	-
   Requirements	*	**	*	*
   Design	*	*	**	*

   
   (Close Table)
   The disciplines are like tools that are used in many phases. However in the early phases we normally do more business modeling and requirements than Design and Implementation. In later phases this is reversed.

   1 page 17 Domain Models

   What is a domain model and how does it relate to the UML process?

   UML is not a process. It is a family of 13 types of diagram. The process we will be learning is the Unified Process or UP. UML is the "Unified Modeling Language". We use it to prepare artifacts (documents). The UP will guide what diagram we will be drawing at any particular time.

   A Domain Model is also known as a Business Model. Creating and changing one is part of the Unified Process. It describes the real world that your software will interact with. A full business model will include many kinds of diagrams and text documents describing how the business works, the data that it uses, the hardware and software platforms to be used. It should also have a conceptual class diagram that summarizes the kinds of things and relationships between them that are important to the stakeholders.

   In this course we will often refer to the conceptual model (classes of real objects and their relationships) as "The Domain Model". It will be an important source for the classes that we put into our designs.

   In other words, real world ideas (domain model) will inspire the structure (Design class diagrams) of our software. As a result, the software should (1) fit the world better, (2) be easier to understand, and (3) be easier to change when the world makes a small change.

   The way these artifacts(documents) fit together is shown inside the front cover of the hardback edition of our text book.

   2 page 18 Length of an iteration

   How would you estimate what the proper time would be for the iteration period?

   Each project and each iteration may have a different deadline. There are no simple and accurate rules. I like short deadlines -- in senior projects I ask students to show me what they have got every week -- verbal report. What works? What can you do next week. This is the best length for college work. Similar to the XP weekly cycle. Most methodologists think 1 week is too short.

   The time for an iteration should be enough to analyze, design, implement, and test something.

   Key point: fix length and then choose what to do in it.

   The simplest rule I know is to use past performance to predict the future. Suppose you already have implemented a dozen similar features and they have each taken an average of one 40 hour week... then adding another similar feature should take another 40 hour week. So with a two week iteration -- add two such features.

   2 page 23 Waterfall process

   I understand the idea of the waterfall cycle (process) but i don't understand how that name describes or even relates to my understanding of the waterfall cycle. Is it because you don't see it coming when you start?

   Interesting question. It comes from a paper by Winston Royce "Managing the development of large software systems" (Proc IEEE WESCON (1970) pp328-339) which had a picture with data flowing down from analysis to Design etc. like water down a series of steps... [ royce.waterfall.pdf ] (PDF). Oddly the paper is arguing that the waterfall process can not work. Royce wanted iteration, prototyping, and starting with code!

   2 page 23 waterfall polluting agile process

   Why is it that iterative projects with a "waterfall" influence are likely doomed to failure as if they were strictly waterfall projects?

   They loose the feedback from implementing and testing. A recent government project had to tams working in parallel. At the the end of 18 months the agile team had 80% of the project running, the waterfall team had not finished the specification.

   Alternatives to UML

   Are their any other systems besides UML that can model software development? If so what are their names?

   Yes -- but they have died.... HOOD, OPEN, ... see [ ../samples/methods.html ]

   2 page 28 which requirements to do first

   How is it determined....which requirements are going to be done at a particular iteration?

   Look at the risks involved -- tackle the riskiest thing first.

   Waterfall

   Do you know of any software development company that actually was successful using the waterfall method?

   None come to mind.... but dozens of simple projects are done in one iteration = waterfall. However, Alistair Cockburn, who has done a lot of consulting on large scale projects, has observed successful projects using any process! He also seen all processes fail. He writes

   ---

   1. The people on the projects were not interested in learning our system.
   2. They were successfully able to ignore us, and were still delivering software, anyway.
   3. Almost any methodology can be made to work on some project.
   4. Any methodology can manage to fail on some project.
   5. Heavy processes can be successful.
   6. Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.

   ---

   [Cockburn00]

   2 pp 18 -- unified process vs. rational unified process

   I'm having trouble understanding the difference between unified process and rational unified process can you explain the differences

   They have the same philosophy, phases, and come from similar experiences.

   The differences are:
   

   1. RUP is more complex and complete -- more disciplines are involved.
   2. You buy RUP from IBM.
   3. I don't think Craig Larman is licensed to teach RUP.
   
   

   The Rational Unified Process phases and Disciplines

   There are more disciplines involved in the RUP: [ File:RUP_disciplines_greyscale_20060121.svg ] and [ rup_discipline.jpg ] (if this is Bad link - try Google Images and search for RUP)

   You can compare the UP and RUP with Barry Boehm's [ boehm.jpg ] similar iterative Spiral process [ spiral.gif ] which, may still abandon work on requirements too early...

   2 Pages 18-19 Model or framework

   UP is described a method as well as XP and SCRUM. Can UP be considered then a model or a framework? Can these adjectives be used interchangeably to describe those interactive processes?

   The author does not clarify the terms. It is a bit confusing! Model, Method, Framework, Process?

9. Model::=description of something of interest in a project. Example: class diagram of classes in code.
10. Method::=steps to take to achieve a goal. Example: SP, OOAD, ...
11. Framework::=loose structure with customizable bits -- can be a method, Model or a process. Describes a family of possibilities.
12. Process::=how a team works together and schedules its time to complete a project. Examples: XP, SCRUM, ...

    
    (Questions): See [ 02q.html ]

    
    (Exercises): Closed Book
    

    1. List the four steps used to apply OOAD to a simple example.
    2. What is a domain model? How does it differ from a design class diagram?
    3. Each arrow in an interaction diagram become something in a design class diagram, is it a class, an attribute, or an operation/function?
    4. Name the three ways to apply UML. (pages 11-12).
    5. Name the three perspectives to apply UML (page 13).
    6. What does time-boxed mean? Where does it apply in this course?(page 23)
    7. Name the 4 UP phases.
    8. Name the 3 disciplines covered in the text.
    9. How do iterations and phrases fit together?
    10. Draw a diagram showing the disciplines, phases, and iterations (page 36).
    
    Open Book
    
    1. On page 29 is a copy of the Agile Manifesto and the Agile Principles. In a group of 4 or 5 people form a consensus opinion about which principle you think is most controversial.
    
    

    Next

    See table at head of page.... Prepare by looking at [ 03.html ] and then studying pages 41-59 on the inception phase combined with the projects completed in CSci372.

    Project Kickoff

    This time people from CS372 will briefly present their projects to the class. People who are not from CS372 should choose a team to join or propose their own project.

    You also need to look at [ projects.html ] to get an idea of what is going to happen. Also see [ w1.html ] the first assigned piece of project work. Today we will get started on preparing for this. At the start of the next class hand in a first draft of:
    

    1. Name of the project
    2. List of team members
    3. One paragraph vision
    4. One Paragraph business case
    5. Some users and what they will want to get out of the system
    
    You will get feedback and be able to complete and resubmit the following week.

    Review Questions

    [ 02r.html ]

    Standard Definitions

13. CS202::= See http://cse.csusb.edu/dick/cs202/.
14. CS372::= See http://cse.csusb.edu/dick/cs372/.

15. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
16. DRY::XP="Don't Repeat Yourself".

17. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

18. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
19. GoF::="Gang of Four", [ patterns.html#GoF ]
20. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
21. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

22. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

23. OO::shorthand="Object-Oriented".

24. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
25. patterns::="Documented families of problems and matching solutions", see Patterns.
26. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

27. Process::="How to develop software".

28. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
29. RUP::Process="Rational UP", a proprietary version of UP.

30. SSD::="System Sequence Diagrams", see chapter 10.

31. TBA::="To Be Announced".

32. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

33. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

34. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it means "It won't be on the final or in quizzes".

35. XP::="Extreme Programming", the ultimate iterative code-centric, user-involved process.