design ( how )
DESCRIPTION
Design ( how ). Architecture GRASP Realization of use cases in interaction diagrams Design class diagram. From analyses (what) to design (how). Specification of the requirement is looking at the system from the outside. - PowerPoint PPT PresentationTRANSCRIPT
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