Use Case Modeling

Information taken from: http://www.devdaily.com/java/java_oo/node26.shtml

————————————————————————————

Purpose of a use case is to capture user requirements of the new system.

Use case is a sequence of actions that an actor performs within a system to achieve a particular goal. Actor can be a role a user plays with regards to a system.

Basic course flow must always be present but alternate course flows (exception / error condition) are not needed.

It should list all required system functionality.
Association lines show the relationships.

Domain Modeling

Information taken from: http://www.devdaily.com/java/java_oo/node25.shtml

————————————————————————————-

1. Build the classes.
2. Build the generalization relationships.
3. Build association between the classes.

————————————————————————————-

Class
A template for creating objects.

In a class there are attributes and behaviours that an object will have.

Object
Is a specific instance of a class.

Attributes
Data variable with object scope.
Value of an object’s attribute is its state.

Example:
Book attributes – title, author, publisher, ISBN
Value of the attributes are states.

Attributes should not be accessible to entities outside of the object.

Behaviours
Written in the methods or functions. It can operate on the object’s attributes.
Methods define the objects responsibilities.

Generalization
One class is a refinement of another class (parent child classes).

Association
Static relationship between 2 classes.
Shows dependencies between classes but not between actions.
Involves one to one, one to many, multiplicities.

Aggregation
Is an association whereby one class is made up of other classes.
Classified as “HAS-A” and “PART-OF” relationships.

Unified Modeling Language (UML) Diagrams

Information taken from: http://www.devdaily.com/java/java_oo/node15.shtml

————————————————————————————-

UML gives a graphical representation for developers, architects to model a software system before it gets built – the blueprint plans before the building gets started.

UML diagrams:

1. Use case
2. Class
3. Interaction – Sequence and or Collaboration
4. Package
5. State
6. Activity
7. Component
8. Deployment

————————————————————————————

Use Case Diagram
Interaction between a user and a computer system.

Class Diagram
Describes the types of objects in the system and the static relationships between them. Static relationships includes 2 kinds – association (HAS-A) and subtypes (IS-A).

Sequence Diagram (Interaction)
Flow of entire use cases related to time ordering. One sequence diagram to follow the flow of the entire use case (basic and alternative flows for each of the use cases).

Collaboration Diagram (Interaction)
Shows how critical objects collaborate within a use case. Focuses on key transactions and adds the details in relation to timing of messages.

Package Diagram
Classes are arranged into logically ordered packages. Shows relationships and dependencies between the packages. Vital especially for large projects.

State Diagram
Lifecycle of one or more objects.

Activity Diagram
Advanced version of flowcharts. Has swimlanes to organise the set of activities in accordance to whom is performing.

Component Diagram
Implementation view of a system displaying the organisation and dependencies between software components.

Deployment Diagram
Environment view of a system showing the physical relationships among software and hardware components. The node represents computational unit (hardware). Connections are the communication paths.

Object Oriented Concepts

All information taken from: http://www.devdaily.com/java/java_oo/node9.shtml

 ———————————————————————————— 

1. Encapsulation
2. Inheritance
3. Polymorphism

————————————————————————————

Encapsulation
It groups related ideas / items in one unit and has the attributes and behaviours placed together.

The implementation details cannot be seen from the outside world. Considered “hidden”. An analogy example: we know how to use a phone but we don’t care how it works. We know how to make purchases on an ecommerce website but we don’t care how the shopping cart is being programmed.

Packaging of the attributes and operations represents a state in the object type. However that state is accessible or modifable only through the object’s interface.

Through encapsulation it lets builders of objects reuse already existing objects.

Inheritance
Derived from a superclass which is then called a subclass. It takes on the attributes and behaviours of the superclass and override the behaviour.

Commonly describe this as “IS-A”.

Promotes “reusability”.

Polymorphism
Have many forms / many different forms of behaviour. Expresses this for set of classes with a common superclass. The operation / attribute can be defined in many classes and each class has different implementations.

An attribute may point to different objects at different times.

Abstraction
Classes are abstracted from concepts. Identifies software artifacts to model problem domain.

Course Registration System

The Course Registration System allows Students to be registered. There is a Student Class where the attributes is Name, and 3 classes they enrolled to.

—————————————-

package courseregistrationsystem;

public class Main {
    public static void main(String[] args) {

        //Create computer registration of another 9
        Student s1 = new Student(“JT”, “ci6201″, “ci6202″, “ci6203″);
        Student s2 = new Student(“TJ”, “ci6203″, “ci6204″, “ci6201″);

        for (int i=1; i<3; i++) {
            switch (i){
                case 1:
                    System.out.println(s1.getName());
                    System.out.println(s1.getClass1());
                    System.out.println(s1.getClass2());
                    System.out.println(s1.getClass3());
                case 2:
                    System.out.println(s2.getName());
                    System.out.println(s2.getClass1());
                    System.out.println(s2.getClass2());
                    System.out.println(s2.getClass3());
                default:
                    ;
            }
        }
    }
}

Course Registration System: Student Class

package courseregistrationsystem;

public class Student
{
      //add student name
     //add 3 courses as attributes of a student
    String Name;
    String Class1, Class2, Class3;

    public Student(String name, String c1, String c2, String c3)
    {
         Name = name;
         Class1 = c1;
         Class2 = c2;
         Class3 = c3;
     }

    public void setName(String name)
    {
        Name = name;
    }

    public void setClass1(String c1)
    {
        Class1 = c1;
    }

    public void setClass2(String c2)
    {
        Class2 = c2;
    }

     public void setClass3(String c3)
    {
        Class3 = c3;
    }

    public String getName()
    {
        return Name;
    }

    public String getClass1()
    {
        return Class1;
    }
    public String getClass2()
    {
        return Class2;
    }
    public String getClass3()
    {
        return Class3;
    }

}

Overview and Week 1

Overview

50% exam, 50% project

Managing large amount of information in an engineering perspective.
Need to do basic programming.
Will be looking at the OO side (high level concept).

 Objective: To make high quality, complex large systems to last a sufficient long time which can deal with changes and new features, etc.

Software Engineering: engineering of software whereby will last a long time – resistant to change and can maintain.

 ————————————————————————————-

 q) What does it mean to be doing “engineering”?

Describe each stage of engineering process and looks at the tools for the stages.

Iterative process going through clockwise cycle.

Look at UML (modeling language) from clients, design patterns, GUI (elaborated in human computer interaction class), Java programming.
Note: Keep in mind that the project cannot be done by 1 person. A project so big has its own sets of challenges.

Will be looking at some quantitative matters. Project will be built upon the system from the labs. 

Look at pass year papers to see what kind of questions are usually asked.
Looking to have a better appreciation in why we want Engineering approach to Software Design Development. 
1^st stage – needs in all sorts of formats and forms.
Involves large group of people.
Constraints (eg time, cost, resources)

 Qualities of “user needs” to “solution”.

Using “Engineering” – Analysis / Models / Designs / Testing

Software – 3 types
1) Commercial off the shelf (COTS) – MSOffice, SAS, Oracle, etc
2) Custom made – will be looking at software development in this category
3) Embedded – built into hardware

 Software Crisis
Software is a product (can’t really hold and visualize thus intangible)
Can’t determine the efforts behind it. Can’t tell if its good / bad software until one uses it.
Software crisis happens when people underestimate amount of time to develop software. Software system delayed or never delivered or quality is poor.
Keep in mind how to avoid software crisis.
Software crisis whereby system is not used is when requirements was not sourced out properly.

Quality – how to identify?
Who is producing and how many? 

Changes you introduce, have you considered the impact it may have? Is there a formal standard for introducing the change? Bugs usually don’t surface until much later. Unpredictable manner when the bugs come out.

What is the Software Engineering approach?
1)      Solving customer’s problems – make it as the priority goal. If not it won’t be appreciated.

1. Not to add unnecessary features
2. Buy vs. build
3. Effective communication to identify and understand the problem
4. Allows Software Engineers to know what needs to be done

2)      Systematic development and evolution

1. Apply well understood techniques. There’s well accepted practices which are standards.

3)      Large, high quality software system

1. Large = complex
2. Teamwork and coordination
3. Challenge dividing up the work
4. End product should have quality

4)      Within cost, time and constraints

5)      Software quality

1. Usability
2. Efficiency
3. Reliability
4. Maintainability
5. Reusability – In other future projects to save time, cost and constraints

Benefits must outweigh cost

3 types of projects
1)      Evolutionary, Maintenance, Work on Legacy Systems
2)      Greenfield – from scratch and lets flexibility
3)      Build on framework – plug together components already developed 

Requirements and Specifications – from customer and make it form of specifications
1)      Domain analysis
2)      Define the problem
3)      Gather requirements
4)      Requirements analysis – have to define the scope in the final system
5)      Requirements specifications – acts as formal communication document in the team 

Design:
What hardware and software support the system.
High level architecture – identify components and internals 

Quality assurance via testing – must have formal documentation.

9 themes to keep in mind.
Want to see information in the forms of concepts (object orientation).
Many objects with own attributes and behaviors, see their form of interaction and association. “Suppose to be good”

Want to see things quantifiable: whether it’s good or not good.
Iterative and agile.
Communicating using documentation – important element
Need to know how to deal with risks and changes – risk management