[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 08.html Wed Jan 11 07:25:38 PST 2012

Opening Microsoft files (winzip, word, excel, powerpoint) on this page may require you to download a special viewer. Or you can download and save the files and use your preferred office applications to view and edit them.

Contents


    CSci 375/08 SSDs


    Table
    Date #Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous 7Domain Model II157-171Q3(121-171)-
    Today 8SSDs173-196-W3(Domain Model 1)
    Next 9Packages197-219Q4(173-219)-

    (Close Table)

    Revision History


    Table
    Version# DateDescriptionAuthor
    0 2005-01-03Used boiler plate to make templateRJB
    1 2005-01-31Input section headingsRJB
    2 2005-02-07Adding QuestionsRJB
    3 2006-01-12Update to 2006RJB
    4 2007-01-10Add link to projectRJB
    5 2007-02-07Added notes on format of messagesRJB
    6 2008-02-07Added notes on SSDs and testing in C++RJB
    7 2009-03-18Added instructions on writing messagesRJB
    8 2011-01-26Expanded syntax of messages and added PPTRJB
    9 2011-02-02Adding Exercise stubsRJB

    (Close Table)

    10 SSDs

      Introduction

    1. SSD::="System Sequence Diagram", a way of using the UML to model the sequences of events flowing between actors and the system under development.

      SSD's clarify the steps in use cases and prepares you to design collections of objects that realize a use case.

      Each SSD should show a scenario with one event/response for each interaction between an actor and the system. These events should be thought of as coming from the user interface into the heart of the software. We will work out what happens inside this next week.

      We will use sequence diagrams with similar form but more objects to design our software. The messages in the SSD will be the incoming "found" messages that we will use to work out how objects in our program will "collaborate" to give the response that the user/stakeholders require.

      It shows a single box(object) for the whole system. It does not show any internals of the system. It is a black box model of the system.

      Example of a SSD

      Powerpoint on SSDs -- old Larman book

      [ Larman%20Chapter%209.ppt ] (429 kB).

      Common error -- SSDs showing how the system works

      I remove points if your SSD does not show the [:System] object and the actors.

      I remove points if you draw an SSD and show objects that are inside the system.

      A common error is to do design before you clarify the steps in an SSD. This shows up by not having a single box called [:System] plus the actors from the use case. The result -- I've seen dozens of these -- especially on the web -- are designs that can not work.

      The purpose is to define the detailed flow of messages and data between the actors and the system as a whole.

      Once this is done it is much easier to design objects to realise each step. Do this later!

      Messages and data

      Messages turn up a lot in OO programs: in SSD, interaction diagrams, and in design class diagrams.

      You should use a strict syntax for messages in UML diagrams.

       		login(id,password)
       		logout()
       		findClassesWith(name)
       		registerIn(me, class)
       		pick(itemNumber)
       		createMailMessage(subject, replyTo, message, signature)
      You aim to be a precise as possible. The idea is to uncover the details that can kill a project, not to slide them underneath a rug.

      Here is the syntax of function calls:

    2. message::= name "(" data ")". The parentheses are important. Do not omit them.
       	 login(userId, password)

    3. message_with_response::= identifier ":=" message, Useful when something valuable is returned by when a message is sent.
       	 reply:=sendEmail(to,subject,body)
       	 music:=playSelectionFromList(selection)
      You can also use a "return" arrows that are dashed and have an open arrowhead. Note -- omit responses that merely say that the message has been handled! KISS!

      Response are just objects. They are data. The data (objects) are sent back in response to a message:

       		confirmRegistration
       		listOfCourse
       		OK
       		MessageOfTheDay
       		acknowledgement, rendered_page
      These are put on dashed arrows with an open "stick" arrowhead.

      Note -- in an SSD you can return several objects inside a single response. When designing the internals of a program you need to be aware that programming languages may require you to pack all the response to a message into a single object. But keep this out of domain models and SSDs! All practical languages support vectors, lists, sets, etc. in some form or other. You can add multiplicities like "[*]" and properties like "{set}" to data descriptions.

    4. data::= empty | datum | datum "," datum "," .... | ... The data is empty, or an identifier, or a list of identifiers.

      You can also specify the class of the data like this

    5. datum::= identifier O(":" className #("[" multiplicity "]" | "{" property "}")), add the type after a colon and then any number of multiplicities and properties as needed.
      	 	messageOfTheDay : Text
      	 	cost : Money
      	 	listOfCourses : Course[*]{list}

    6. name::= event | request_for_action_by_target. You should choose short names that either tell the reader the reason that the message was sent or it is an instruction to the target object to do something.
       		timeOut
       		create
       		playSelectionFromList

    7. empty::="", indicates that the message has no data -- typically one of a small number of events like clicking the logout button.

    8. identifier::=lowerCaseWord # UppercaseWord, the data in a message either is an element like a number, character, or string. It can also identify an object. You send an object in a message so that the receiving object can do things to it ... like send back a response or extract more data.

      Put messages on an arrow with a filled in head. Put returned objects on lines that are dashed with an open arrowhead.

      Common Error -- Not putting the data in messages

      Whne the user supplies data -- you must name it and show it in messages. When the system responds with data you must name it. The names must be clear.

      For example, a diagram that shows a login message but does not show the data used to identify and authenticate the user is wrong. It can not work.

      Even if your diagram shows a messahe "login()" sent to an object "[:User]" it can not work -- (1) which user? (2) How did you find it, (3) what! no password!

      Again a common step is when the user elects an item in a list. Do not show this as a message "select()" going to an object "[:Item]", instead

       		selectItemInList(selection)
      is sent to the [:System] in the SSD and it will (probably) route it to [:List]...

      Purpose of SSDs

    9. * Purpose: Given some use cases, refine some of their scenarios.
    10. * Prepare to design objects to handle use cases.

      Text -- chapter 10

    11. * Fig 10.1 Artifact influences
    12. * 10.1 Example: NextGen SSD
    13. ** 10.2 Definition of SSD
    14. *** 10.3 Motivation: why draw a SSD
    15. *** 10.4 Using the UML to draw a SSD: operation calls, operation data, returned values.
    16. +++++ Get the arrowheads right!
    17. * 10.5 Relation between Use cases and SSD: one scenario per SSD.
    18. *** 10.6 Naming events: See Messages above. Keep them "essential" -- express the intent not the actual physical action by the user.
    19. ** 10.7 Collaborations with other systems
    20. 10.8 SSD -> Glossary?
    21. 10.9 Example: Monopoly SSD
    22. ++ Exercise: why do I give this SSD a B grade rather than an A?
    23. * 10.10 Process: Iterative, Evolutionary. Mainly during elaboration.
    24. 10.11 History. I knew Derek Coleman and have the Fusion book in my office... you can forget this:-(

      SSDs and C++ Testing

      You can quickly create a main program that will test your design directly from the SSD becasue testing doesn't have a complex User Interface.

      For example the SSD above would lead to a C++ main Program like this

       ...
       #include <WhereTheClassesAreDeclared.h>
       int main()
       {
       	SomeClass * testObject = new SomeClass(someValues);
       	testObject->event();
       	someType response = testObject->event2(data);
       	assert ( someProperty(response) );
       }
      However.... you don't know what "SomeClass" will be until you've designed the internal interactions. See [ 10.html ] later.

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

    11 Operation Contracts

    1. * Work out how operations in the SSD effect the system as a whole.
    2. ** Complex systems only!

    3. Artifact influences
    4. ** 11.1 Contract: operation, cross ref, preconditions, postconditions
    5. * Example: enterItem
    6. * 11.2 Sections in an operation contract
         .Open Contract name
         . Operation message(argument2)
         . Preconditions
         . Postconditions
         .Close

    7. * 11.3 What is a System Operation.
    8. * 11.4 Post Conditions
    9. ** 11.5 Example
    10. * 11.6 Update the Domain model?
    11. ** 11.7 Guideline: When to use: only complicated steps in complicated systems.
    12. * 11.8 Guideline: How to do it
    13. ** 11.9 Examples from NextGen
    14. 11.10 Example from monopoly
    15. 11.11 UML contacts? May use the Object Constraint Language(OCL)? Or formal logic
    16. OCL::="Object Constraint Language", [ ../samples/ocl.html ] for more details.
    17. Example OCL FYI
           	context FamilyTree::birth(f:Person, m:Person, bday:Date)
           		post: self.father=f and self.mother=m
           			and self.birthday = bday.

    18. ++ I cover many ways to express, check, and process logic in my Formal Methods elective courses. [ ../cs556/ ]
    19. 11.12 Process
    20. 11.13 History
    21. 11.14 Resources

    . . . . . . . . . ( end of section Operation Contracts) <<Contents | End>>

    Requirements to Design

    1. * Introduction
    2. ** 12.1 Do the right thing, do the thing right
    3. *** 12.2 Provoke changes early!
    4. 12.3 How long did that take?

    . . . . . . . . . ( end of section Requirements to Design) <<Contents | End>>

    SSD on the web

    [ umlsyssequence.html ] (arrow heads are wrong).

    What examples can you find on the internet?

    Another example SSD -- Use Case: Teacher posts grades


    1. Teacher logs in.
    2. Teacher selects a course.
    3. Teacher posts the grades for that course.
    4. Teacher checks the student IDs for that course.
    5. (repeat above three steps for each course in turn).
    6. Teacher logs out.

    UML1.4/Rational Rose 2003 [ 08SSD2.gif ] , Visio UML2.0 [ 08SSD3.gif ] , and Dia in CSci CSUSB Labs [ 08SSD4.png ]

    Questions and Answers on SSDs

    [ 08q.html ]

    Review Questions

    [ 08r.html ]

    Exercises

    [ 08x.html ]

    Next: Logical Packaging etc

    [ 09.html ]

    Next Project Iteration -- Domain Model 1

    [ w3.html ] due start of class 09.

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.
  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. 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 ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. 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.

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

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

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

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

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

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

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

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

  21. 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 now. In this class it also means "It won't be on the final or in quizzes".

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

End