SE450: Lecture 2 (The UML, Object Oriented Development, Intro to Patterns)

Review Homework assignment

Introduction to the UML.

• UML class diagrams.
• UML object diagrams (sequence, collaboration, state)
• UML use case diagrams

CRC Cards

Development Methodologies

• XP - eXtreme Programming
• RUP - Rational Unified Process

More 00/Java

Homework Assignment #2

So...here's one possible solution.

Bags - a.k.a MultiSets. This is a Collection in Java

Sets - unorderd collection. This is a Set or SortedSet in Java

Lists - ordered collection - This is a List in Java

Map - unordered collection of key/value pairs. This is a Map or SortedMap in Java.

Iterator - allows traversal of a Collection

Software Development usually involves:

• Requirements Analysis
• Design
• Implementation and Unit Testing
• Inteagration and Systems Testing
• Maintenance

In the waterfall process, these were just done in big blocks, one at a time

Usefulness

Timeliness

Reliability

Maintainability

• flexibility
• simplicity
• readability

Reusability

User Friendliness

Efficiency

When doing OO development, it has become clear over the years that the old style of waterfall life-cycle development consisting of analysis, design, and construction doesn't work (but companies companies continue to use it anyway).

This doesn't mean uncontrolled development with no planning

Instead, each increment of the system builds a subset of the entire system. An increment includes

• Conceptualization
• OO Analysis and Modeling
• OO Design
• Implementation (Coding, Testing, Integration)
• Packaging, optimization, etc (if delivered to an end user)
• Maintenance

Before the first increment is executed, an exploration phase is entered. This phase consists of

• Finding Use Cases
• Developing a model of the problem domain
• Developing an architecture

The Rational Unified Process is a process that was developed by Rational Software. They define it and sell it as a product that integrates with other tools that they sell, but the process can be used separately from the tool.

The key practices of RUP are:

• Develop software iteratively.
• Systematically elicit, organize, and manage changing requirements.
• Use component-based architecture.
• Visually model software using UML.
• Continuously verify software quality.
• Control changes to software.

There are 9 models

1. Business
2. Domain
3. Use Case
4. Analysis
5. Design
6. Process
7. Deployment
8. Implementation
9. Test

There are 9 process workflows

1. Business modeling
2. Requirements
3. Analysis and Design
4. Implementation
5. Test
6. Deployment
7. Configuration Management
8. Project Management
9. Environment

There are 4 phases to RUP:

• Inception - project start. In this phase, the business and requirements risks are evaluated, the business case is defined, scope is defined, a candidate architecture is created (maybe with a prototype) and the project environment is prepared.
• Elaboration - define the architecture and provide a stable basis for Construction. Refine the vision, create and basiline the iteration plans for Construction. Create the Software Architecture Diagram.
• Construction - completes development of the system. Each iteration manages resources and controls the process, develops and tests components, and assesses the iteration (to refine future estimates).
• Transition - includes testing, finalizing support material, fine tuning, and delivery. Usually comes with a Deployment Plan, Release Notes, and Training Materials and Documentation.

The last three phases may contain multiple iterations.

Certain documents are maintained throughout the project:

• Risk List - risks listed with mitigation strategies
• Project Plan
• Various UML documents - as needed
• Software Architecture Diagram (SAD)

"Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation."

There are 13 core practices in XP.

1. Whole Team: XP centers around the "whole team", with the customer being the business representative who sits with the team daily.
2. Planning Game: The customer presents the desired features to the programmers, they estimate how long it takes to complete. The customer then plans what goes in the release. An iteration is performed every 1-2 weeks, and the programmers present to the customer what they can complete. The customer decides what goes in each iteration. Each iteration is a working version of the code.
3. Customer Tests: The customer defines tests that prove to them that the system is working. The programmers write these and run them (they are automated) to prove the release is working.
4. Small Releases: Every iteration works. The team also releases to the end users frequently.
5. Simple Design: Design is continual, not just up front. Through unit testing and refactoring, the design is kept simple and improved continually.
6. Pair Programming: Programming takes place in pairs. Improves code, communication, and training.
7. Test-driven Development: Write tests first. Run them before code is checked in, and every time it is updated. Here is an excellent example of this.
8. Design Improvement: Code is refactored. Increase cohesion, lower coupling. We'll look at some refactoring examples soon.
9. Continuous Integration: Multiple builds a day. Cuts down on integration problems.
10. Collective Code Ownership: Everyone owns all the code. Anyone can change any code. Prevents programmers from putting functionality in the wrong place.
11. Coding Standard: Team follows a common coding standard
12. Metaphor: A common description of the program, and a common system of names. Everyone should understand how the system works and where the code should go for new features.
13. Sustainable Pace: Minimize overtime. In general, this means no overtime two weeks in a row. (40 hour work week)

The Unified Modeling Language is the successor to a number of Object-Oriented analysis and design (OOA&D) languages

The UML is a language, not a development methodology (we'll talk about methodologies later). It is a language for visualizing, specifying, constructing, and documenting.

OO Modeling languages started to appear in the late '70s and early '80s, with more than 50 approaches in the early '90s

Mostly a combination of the work of Booch, Rumbaugh, and Jacobson (the three amigos)

• Booch, Jacobson - Object Oriented Software Engineering (OOSE)
• Rumbaugh - Object Modeling Technique (OMT)
• Fusion, Shlaer-Mellor, Coad-Yourdon, etc

Three goals stated for the UML

1. To model systems, from concept to executable artifact, using OO techniques
2. To address the issue of scale inherent in compolex, mission-critical systems
3. To create a modeling language usable by both humans and machines

By the later '90s, most notable software tool vendords had adopted the UML as their OO modeling language

UML maintenance (of the specification) is now under the control of the Object Management Group (OMG)

What about tools for UML?

Most companies select a UML tool that integrates with their IDE and programming languages

Unfortunately, most of these are fairly complex and expensive. However, in the past few years, a number of free versions, and open source versions, have come available. There is a list at http://www.objectsbydesign.com/tools/umltools_byCompany.html that you might find helpful. Unfortunately, I don't have time to review any of the tools or give you support on using them, but you are encouraged to try some of them. I will always accept drawings by hand for the final project (assuming they are legible and correct).

I have tried Posieden and ESS-Model. You may find others more (or less) helpful. Some of the non-free versions have limited time versions that might work for this class.

Newer versions of Visio support most of the UML diagrams, but will not support reverse engineering of code (from non Microsoft tools).

Importance and Principles(from The Unified Modeling Language User Guide, by Booch, Rumbaugh, and Jacobson):

Importance

• Consider building... a dog house, a house, a skyscraper
• A model is a simplification of reality
• Build a model so you can further understand the system you are building

Models help us:

1. Visualize the system as it is or we want it to be
2. Permit us to specify the structure or behavior of a system
3. Give us a template that guies us in constructing a system
4. Document the decisions (usually design decisions) that we have made

You need models for larger systems because you cannot comprehend the system in its entirety

Principles of Modeling

1. The choice of what models are created has a profound influence on how a problem is attacked and how a solution is formed.
2. Every model may be expressed at different levels of precision This one is important for you to remember when working on your project
3. The best models are connected to reality
4. No single model is sufficient

Use Cases exist to capture the intended behavior of a system without having to specify how the behavior is implemented. They are very good for specifying user requirements, and for developing good user acceptance tests

Example: p 45-46

Scenario: a sequence of steps describing an interaction between a user and the software system.

Use Case: a set of scenarios that meet a common user goal. Each use case has a name as well.

Use cases are written out as a series of Main Success Scenarios (Main flow of events), and a set of alternative Scenarios (Exceptional flow of events)

Use cases describe what not how

Use cases can be diagrammed using UML. They consist of actors (users of the system) and the use cases that they interact with. The actors carry out the use case.

Use cases can use inclusion and extension. Both of these cases help you save time writing and diagramming. This is similar to generalization, but it limits the generalization to only certain extension points. It is a special case.

For use cases c1 and c2

• c1 includes c2 means that the use case c2 is part of use case c2
• c2 extends c1 means that use casae c2 is a special case of use case c1

Three perspectives

• Conceptual
• Specification
• Implementation

Conceptual - not a direct mapping to classes. Generally is language independent.

Specification - Interfaces, not the implementation. Types rather than classes.

Implementation - lays the entire thing bare.

Shows classes, interfaces, and their relationships (collaborations, generalizations, associations, and dependencies)

Notation:

Top is the class name (required)

Fields (attributes in UML) in the middle. Two types of syntax: Java or UML.

Java Syntax: [Visibility] [Type] Name [[Multiplicity]] [= Initial Value]

UML Syntax: [Visibility] Name [[Multiplicity]] [:Type] [= Initial Value]

Methods (operations in UML) on the bottom. Two types of syntax: Java or UML.

Java Syntax: [Visibility] [Type] Name ([Parameter,...])

UML Syntax: [Visibility] Name ([Parameter,...]) [:Type]

Visibility can be one of

• public (+ | public)
• private (- | private)
• protected (# | protected)
• package (~)

Parameters in UML are given Name:Type, in Java Type Name

Class Diagrams can be given in abbreviated forms

Static is indicated by underlining the method

Stereotypes are used to extend the UML. It is like an adjective to describe a core UML type and make it better understood when there is not UML type to describe exactly the role you are assigning a part of your model

Interfaces are drawn as a stereotype of a class (older versions will show a circle)

Constructors can be distinguished from other methods by using a Constructor stereotype

Ellipsis (...) are used to show that more methods or variables exist that aren't shown

Relationships

• Association
• Generalization
• Dependency
• Constraint Rules

Association - relationships between instances of Types.

• Name
• Role
• Label with direction
• Direction (navigability)- bi-directional or uni-directional
• Cardinality - (multiplicity)

Aggregation

• has-a or part-whole
• open diamond

Composition

• a more limited aggregation relationship
• assumes aggregate class has control over the lifetime of the component
• exclusive ownership of component by aggregate class
• closed (black) diamond

Generalization (Specialization)

• Inheritance (class/class or interface/interface)
• Subclassing
• Realization (class/interface)

• interface-inheritance (subtyping) shown with a dashed line and filled arrowhead
• implementation-inheritance (subclassing) shown with a solid line and filled arrowhead
• Abstract classes and methods shown in italics

Dependency - dashed arrow with open arrowhead

Constraint Rules

Design By Contract and assertions will be used to enforce contraints. This is native to languages like Eiffel. We'll talk more about this later.

Examples: p 31,33,35

CRC (Class-Responsibility-Collaboration)

On a 4x6 card, write Class

Responsibility = summary of attributes and methods. A high level description of the purpose of the class.

Collaborations = classes needed by this class to fulfull its resonsibilities.

Very informal. Meant to promote discussion. Use with Class and Interaction diagrams.

Used for larger systems to show dependencies between packages.

Packages dependencies are not transitive.

The goal is to keep dependencies to a minimum.

Note: Java's package import statement can be easily broken. Dependencies could exist that you don't see in the import statements.

Example: p 26

Read Jia Chapters 4 and 5. Pay special attention to the StringTokenizer, the BufferedReader, and the FileReader as you read chapter 4.

Read pages 1-23 of Principles and Patterns by Robert Martin.

Goal: Learn more of the Java APIs. Practice writing more code, debugging, and using multiple source files. Develop some base code for further homework assignments. Improve practices from first homework assignment.

Assume that you have a file of flight records. It is a text file in which each line contains a single record, and each record consists of the following colon-delimited fields:

Airline Code: Airplane Type: Flight Number : Departing Airport : Arriving Airport: Time

A sample line is as follows:

ASA:B73Q:144:ORD:SFA:13

Assume that the time is just a whole hour in 24HH format, as an integer. All other records are strings

Write a Java application that will read in a data file from a command line argument and do the following:

• Read in all of the flights in the file.
• Instantiate one Airline object for each Airline in the file (i.e. multiple flights should share a reference to the same Airline)
• Instatiate one Flight for each flight record in the file.
• Store the Flights and Airlines in an appropriate Collection.
• a) Print a list of destination airports in alphabetical order, where each airport is followed by the next arriving flight information (if a tie, print them all)
• b) Print each airline with the next arriving flight (regardless of city)
• c) Print the airline with the most flights (if a tie, print them all)

Implement the solution in at least two source files, one called se450.studentid.hw2.Main, one called se450.studentid.hw2.Airline, and one called se450.studentid.hw2.Flight. Replace studentid with your DePaul id.

Choose a good container for the flights as you work with them in your code, and use an Iterator when you have to traverse the collection of flights.

The Flight class should contain a reference to the Airline, and store the airport codes and airplane types as Strings. The time should be stored as an Integer.

Override toString to provide a meaningful String representation of the flight.

The program should take one argument, the filename of data, and provide the output for parts (a), (b), and (c) all at once. If you are having trouble with "screen blindness", then redirect the output to a file for offline reading like this: java se450.studentid.hw2.Main flights.txt > output.txt

Ask questions on the discussion board!

Submit a zip file that contains all necessary .java files as well as grader.txt, in the correct package structure, just as last week.

Don't include any class files

Due next Monday at 5:30 PM.

Revised: 2003/1/12