Programming in JavaUnit 3

• Learning outcome: LO2: Be able to design Java solutions LO3: Be able to implement Java solutions

• Assessment criteria: AC2.1: Design a Java programming solution to a given problem AC3.1: Implement a Java programming solution based on a prepared design AC3.2: Define relationships between objects to implement design

requirements

• Learning objectives

•  After studying this unit, you should be able to: Create a requirements model using UML notations based on user requirements,

and to analyze requirements models for correctness and quality. Create various UML diagrams using specialized applications/software to model

an object-oriented system. Comprehend enough Java to see how to create software that implements the

Object Oriented designs modeled using UML. Comprehend the nature of design patterns by understanding a small number of

examples from different pattern categories, and to be able to apply these patterns in creating an Object Oriented design.

Determine the collaborations among objects in a system.

Introduction• The Unified Modelling Language (UML) is an industry standard for

object oriented design notation, supported by the Object Management Group (OMG).

• It is becoming widely adopted in many areas of the software and computer systems development community.

• This technique also helps in managing software complexity.

• The basic idea of UML is to improve association of systems analysis and design and try and solve problems through modelling.

• We should therefore be able to use object oriented notation to visualize, construct and document the artefacts of software engineering.

Requirements capture• This describes the UML tools that are to be used to specify clearly how

the system should be constructed to satisfy these requirements.

• The output of the design stage is the design specification.

Use case diagram • This model shows the interaction between system clients and its use cases.

• As developers we should be able to use use cases to capture what a proposed system should do.

• An actor indicates an external person or system which is involved in a use case shown by the stick figure.

• The same person or system may play the role of more than one actor, depending on the context.

• An actor may be a set of roles, which are related.

• An actor may be involved in more than one use case and an actor is normally the initiator of each use case.

• The use case symbol indicates an activity which will supply value to an actor

• Within each use case there must be a description of what this activity does for the actor.

• Use cases can be described by English descriptions - active voice, present tense.

System structure• This part will cover the UML tools that are used to describe the

system’s objects and their interrelationships.

Class diagrams • Class diagrams model classes used in a system.

• All objects identified in the requirements analysis become possible candidates of being classes in the system.

• In a nutshell they specify the structural relationship between parts of the system.

• Class diagrams show the relationship between classes of the system.

• It is divided into three parts namely: class name, attributes and lastly the operations.

System behaviour• This part will explore the system dynamics and basically describe how

the system changes as its objects interact with one another.

Sequence diagram • Sequence diagrams basically depict the sequence of interactions

among objects in a system focusing on when interactions occur.

Activity diagram • This models aspects of system behavior, object’s sequence of events

during program execution.

• This means that it models the actions the object will perform and in what order.

Aggregation • Aggregation “is part of" relationship and is symbolized by a clear

white diamond.

• It is used to indicate that, as well as having attributes of its own; an instance of one class may consist of, or include, instances of another class.

• This is also associations in which one class belongs to a collection.

Composition • Composition “is entirely made of" relationship and is a stronger

version of aggregation.

• The parts live and die with the whole, symbolized by a black diamond.

• Compositions imply coincident lifetime.

• A coincident lifetime means that when the whole end of the association is created (deleted), the part components are created (deleted).

Dependency• Dependency "uses temporarily" symbolized by dotted line often is an

implementation detail, not an intrinsic part of that object's state.

• A dependency exists between two elements if changes to the definition of one element (the supplier or target) may cause changes to the other (the client or source).

• A dependency between two classes means that one class uses, or has knowledge of, another class (i.e., a transient relationship).

• Dependency relationships show that a model element requires another model element for some purpose.

• Dependencies can also indicate relationships between model elements at different level of abstraction.

Test your knowledge • Attempt Self review questions from your e-book, p. 521 - 524

• Toolbox Individual exercise: 1, 2 Group work: 3, 8 Research activity: 1