This document describes the objectives of CSE375 course.
[ old.objectives.mth ]
- Analysis and design IV-6
- Theoretical foundations IV-7
- Communication skills IV-14 (oral + written)
- Collaborative skills IV-16
- Study in an IS environment IV-2
To learn how to express requirements and analyse them to produce a
comparatively stable architecture and maintainable object-oriented design
to meet user's needs, using currecnt notations and techniques.
There should be evidence on file that demonstrates that during CSe375 the students:
- Worked in small groups/teams to analyze systems and propose solutions.
- Presented their work for review by peers, faculty, and IS workers.
- Completed a UML model for a computerized solution to a problem in an existing system.
- (Note. The solution may expressed on paper, as a presentation, and/or as a web site.
- It may or may not include simply prototypes.
- It may be a photographic or software record of a presentation.
- Carried out a group simulation of at least one object-oriented program design.
After completing the CSE375 student will be able to:
- Define a use case and give examples.
- Define a scenario and write simple examples of scenarios.
- Distinguish actors from use cases and give examples of actors.
- Use simple UML use case diagrams + scenarios to state requirements.
- Correctly utilize use case extension, includes and generalization.
- Draw object-oriented domain models using UML class diagrams with classes, associations, roles, and multiplicities.
- Extend a domain model to include attributes/data.
- Allocate responsibilities to classes and test result vs scenarios.
- Use UML Package diagrams to anlyse and design stable software architectures.
- Use UML message sequence diagrams to describe interactions between objects.
- Use UML communication diagrams to describe interactions between objects.
- Use UML communication diagram sequence numbers correctly.
- Use iteration and conditions correctly in communication and sequence diagrams.
- Translate between message sequence and communication diagrams.
- Know how to draw, read, and critique a UML class diagram with attributes and operations.
- Cross-validate a use case model plus communication/message sequence diagrams against a class diagram.
- Use the General Responsibility Assignment Patterns to place operations in a design model.
- (Design model = class diagram + either message sequence or communication diagrams).
- Extend simple class diagrams to include generalization, aggregation, and composition.
- Recognise and analyse some simple design patterns correctly: State, Composite, Observer, Factory, Adapter, ...
After completing the 375 a student may:
- Use either CASE tools or low-tech techniques (chalk board, posters, cards) for documentation.
- Use the UML notation for parameterized, active, and interface classes.
- Develop simple prototypes and tests as executable specifications of components.
- Develop a first iteration of a set of components.
. . . . . . . . . ( end of section CSE375 Objectives) <<Contents | End>>
- Artifact::="Anything that is created in the course of a project".
- artifact::=see above.
- DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
[ 02DiceGameClasses.gif ]
- Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
- Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
- GoF::="Gang of Four",
[ patterns.html#GoF ]
- 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 set of objects and/or classes to carry it out.
[ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
- Grades::= See http://cse.csusb.edu/dick/cs375/grading/.
- 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.
- OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
- patterns::="Documented families of problems and matching solutions", see
- Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.
- Process::="How to develop software".
- RJB::=The author of this document,
RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
- RUP::Process="Rational UP", a proprietary version of UP.
- SSD::="System Sequence Diagrams", see chapter 10 and
[ 02DiceGameSSD.gif ]
- TBA::="To Be Announced".
- UML::="Unified Modeling Language".
[ Unified_Modeling_Language ]
- UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.
- 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 also means
"It won't be on the final or in quizzes".
- XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved