ArchitectureGRASPRealization of use cases in interaction diagramsDesign class diagram

Design ( how )

From analyses (what) to design (how)

Specification of the requirement is looking at the system from the outside.Design is to open up the system and deicide how to implement the requirement.

How do the object have to interact to implement the use cases?

which responsibility(methods) do classes need to have?How can the system be implemented on the chosen

platform?

Design activities

Deciding the architectureUse of patternsInteraction diagramsDesign class diagram

From analyses (what) to design (how)The domain model from the analysis will be transformed to a design class diagram

The use case and system sequence diagram description will be used to make interaction diagrams.

The methods and classes from the interactions diagram will be added to the design class diagram

Layered Architecture

Presentation layer is the user interface

The control layer, is controlling the use cases

Model layer is the implementations of the model classes from the domain model and the containers

Typical we need for practical reasons to be able to see the model classes from the presentation layer (called an open architecture)

Design pattern

In object technology, a pattern is a named description of a problem and solution that can be applied to new contexts; ideally, it provides advice in how to apply it in varying circumstances, and considers the forces and trade-offs. Many patterns provide guidance for how responsibilities should be assigned to objects, given aspecific category of problem.

When a pattern is named, we can discuss with others a complex principle or design idea with a simple name.

GRASP

Information ExpertCreatorHigh CohesionLow CouplingController

General Responsibility Assignment Software Patterns.

Controller

Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices:

Represents a use case scenario within which the system event occurs Use the same controller class for all system events in the same use

case scenario.Informally, a session is an instance of a conversation with an

actor.

Now what happens??:????

Cashier

:ProcessSaleJFrame

actionPerformed( actionEvent )

1: enterItem(id, qty) system event

UILayer

DomainLayer

presses button

Information Expert (or Expert)Solution Assign a responsibility to the information expert. the class that has the

information necessary to fulfill the responsibility.Problem What is a general principle of assigning responsibilities to objects?

A Design Model may define hundreds or thousands of software classes, and an

application may require hundreds or thousands of responsibilities to be fulfilled.

During object design, when the interactions between objects are defined, we

make choices about the assignment of responsibilities to software classes. Done

well, systems tend to be easier to understand, maintain, and extend, and there is

more opportunity to reuse components in future applications.

Question In the Nørre Halne Camping A/S case, some class needs to know the grand total of a rent. Which class should that be based on the information above?

What information is needed to calculate the grand total

Part of the domain model

Interaction diagram

Creator

who should be responsible for creating a SalesLinelteminstance?

By Creator, we should look for a class that aggregates, contains, and soon, SalesLineltem instances

CreatorSolution Assign class B the responsibility to create an instance of class A if one or more of

the following is true:. B aggregates A objects.. B contains A objects.. B records instances of A objects.. B closely uses A objects.. B has the initializing data that will be passed to A when it is created (thus B

is an Expert with respect to creating A).B is a creator of A objects.

If more than one option applies, prefer a class B which aggregates or containsclass A.

Problem Who should be responsible for creating a new instance of some class?The creation of objects is one of the most common activities in an object-orientedsystem. Consequently, it is useful to have a general principle for the assignmentof creation responsibilities. Assigned well, the design can support low coupling,increased clarity, encapsulation, and reusability.

Creator

Low Copling

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. An element with low (or weak) coupling is not dependent on too many other elements; "too many" is context-dependent, but will be examined. These elements include classes, subsystems, systems, and so on.A class with high (or strong) coupling relies on many other classes. Such classesmay be undesirable; some suffer from the following problems:. Changes in related classes force local changes.. Harder to understand in isolation.. Harder to reuse because its use requires the additional presence of theclasses on which it is dependent.

High cohesionSolution Assign a responsibility so that cohesion remains high.Problem How to keep complexity manageable?

In terms of object design, cohesion (or more specifically, functional cohesion) isa measure of how strongly related and focused the responsibilities of an elementare. An element with highly related responsibilities, and which does not do atremendous amount of work, has high cohesion. These elements include classes,subsystems, and so on.

A class with low cohesion does many unrelated things, or does too much work.Such classes are undesirable; they suffer from the following problems:. hard to comprehend. hard to reuse. hard to maintain. delicate; constantly effected by changeLow cohesion classes often represent a very "large grain" of abstraction, or havetaken on responsibilities that should have been delegated to other objects.

Design class diagram

Register

enterItem(...)

Sale

dateisComplete : Booleantime

makeLineItem(...)

Captures

Navigability

1 1

Three section box forclass definition.

methods; there are parameters, but unspecified type information

Example domain model to design class diagram

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain Model

Stakeholder's view of the noteworthy concepts in the domain.

UP Design Model

The object developer has taken inspiration from the real-world domain in creatingsoftware classes. Therefore, the representational gap between how stakeholdersconceive the domain, and its representation in software, has been lowered.

1 1

1 1

inspiresobjects

andnames in

conceptualclasses

designclasses