how to construct? chapter five–part i object oriented design
TRANSCRIPT
HOW TO CONSTRUCT?
Chapter Five–Part IObject Oriented Design
Introduction
The object oriented analysis part does not do well on how the system should be build.
This gap is filled by the design phase that provides such details for the implementation.
There are various artifacts that would be used to model the design of the system that evolve from the analysis phase.
2
What it is?
• Designing of object oriented design requires – the definition of a multilayered software architecture, – the specification of subsystems that perform required
functions and provide infrastructure support such interface, business logic and database layer
– a description of objects (classes) that form the building blocks of the system such as main menu, form, etc and
– a description of the communication mechanisms that allow data to flow between layers, subsystems, and objects.
3
Cont…
The input for object-oriented design is provided by the output of object-oriented analysis.
Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design.
Some typical input artifacts for object-oriented design are; Class diagram, Conceptual model, Use case, Sequences Diagram and User interface.
4
Object-Oriented Analysis and Design
Analysis Design Construction
Investigationof problem
Logical solution Code
Object oriented design .. a meaningful engineering representation of
something that is to be built. It is both “the process” that defines the
architecture, components, interfaces, and other characteristics of a system or component” and “the result” of that process.”
As a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction.
6
Cont…
the software architecture how software is decomposed and organized into components and the interfaces between those components.
It must also describe the components at a level of detail that enable their construction.
In the software engineering context, design focuses on four major areas of concern: data, architecture, interfaces, and
components.
7
Design quality ----
At each stage, software design work products are reviewed for
Clarity, Correctness, Completeness, and Consistency
with the requirements and with one another.
8
The software design process
Software design is an iterative process through which requirements
are translated into a “blueprint” for constructing the software.
is generally considered a two-step process: Architectural design describes how software is
decomposed and organized into components (the software architecture) , Class type architecture, Component,
Deployment, persistent diagrams Detailed design describes the specific
behavior of these components.Refined class model ,Statechart, collaboration
9
Software Design Principles
The design should be traceable to the analysis model.
The design should not reinvent the wheel. The design should “minimize the intellectual
distance” between the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
10
Cont…
The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
Design is not coding, coding is not design. The design should be assessed for quality
as it is being created, not after the fact. The design should be reviewed to minimize
conceptual (semantic) errors.
11
Thus
What to design? Some examples are… – Process and association --User Interfaces – Storage – Networking/Distribution
• Each requires the addition of extra classes and associations.
12
13
Software Architecture
Software architecture is the process of designing the global organization of a software system, including:
Dividing software into subsystems. Deciding how these will interact. Determining their interfaces.
The architecture is the core of the design, so all software engineers need to understand it.
The architecture will often constrain the overall efficiency, reusability and maintainability of the system.
14
The importance of software architecture
Why you need to develop an architectural model:
To enable everyone to better understand the system
To allow people to work on individual pieces of the system in isolation
To prepare for extension of the system To facilitate reuse and reusability
15
Contents of a good architectural model
A system’s architecture will often be expressed in terms of several different views
The logical breakdown into subsystems The interfaces among the subsystems The dynamics of the interaction among
components at run time The data that will be shared among the
subsystems The components that will exist at run time, and
the machines or devices on which they will be located
16
Describing an architecture using UML
All UML diagrams can be useful to describe aspects of the architectural model
Some UML diagrams are particularly suitable for architecture modelling and for implementation issues: Class Type architecture (not in UML) Component diagrams Deployment diagrams Persistent diagram Package/subsystem diagram Evolving UI
Class Type Architecture (not in UML)
A common architectural strategy, some might call it a pattern, is to layer the architecture of a system into several layers
Some strategies simply define N layers stacked on top of each other where layer J interacts only with layers J-1 and J+1.
That's an interesting theory, and it clearly makes sense from a logical point of view, but in practice it is found that it isn't quite so simple.
17
Cont…
The following slide Presents a high-level layering strategy for a software application.
The various layers are represented by the rectangles and collaboration between layers by the arrows.
The primary name of a layer is indicated first, and other common names in parenthesis
18
Layered class type architecture19
Cont…
Interface: There are two categories of interface class – user
interface (UI) classes that provide people access to your system and system interface (SI) classes that provide access to external systems to your system
Domain This layer implements the concepts pertinent to your
business domain such as Student or purchase, focusing on the data aspects of the business objects, plus behaviors specific to individual objects
20
Cont…
Process The process layer implements business logic that involves
collaborating with several domain classes or even other process classes. Example – student registration, purchasing
Persistence Persistence layers encapsulate the capability to store,
retrieve, and delete objects/data permanently without revealing details of the underlying storage technology. Often implement between your object schema and your database schema and there are various available to you.
System System classes provide operating-system-specific
functionality for your applications, isolating your software from the operating system (OS) by wrapping OS-specific features, increasing the portability of your application
21
Class Modeling
The class model at the design level will add some additional details than that of the analysis level class model.
Here the focus will be the solution domain rather than the problem domain.
In practice, the analysis level class model will evolve into a design level class model.
This gives the developers the chance to make amendments and modification to improve the quality of the system.
22
Cont…
The design level class model will concentrate on how to implement attributes methods, inheritance, association, aggregation, composition and the likes.
Modeling Methods Methods, also called operations or member
functions, are the object-oriented equivalent of functions and procedures.
The design level will model more information about methods than the analysis.
23
Cont…
The design level may include:Visibility: the level of access to methods
by external objects. To reduce the effect of coupling within a
system, more restrictions on access of methods should be set.
In other words, if a method does not have to be public then make it protected and if it does not have to be protected then make it private.
24
Cont…25
Visibility Symbol Description Proper Usage
Public + A public method can be invoked by any other method in any other object or class.
When the method must be accessible by objects and classes outside of the class hierarchy in which the method is defined.
Protected # A protected method can be invoked by any method in the class in which it is defined or any subclasses of that class.
When the method provides behavior needed internally within the class hierarchy, but not externally.
Private - A private method can only be invoked by other methods in the class in which it is defined, but not in the subclasses.
When the method provides behavior specific to the class. Private methods are often the result of refactoring.
Cont…
Name: Descriptive name for the method. A good name is the one that is capable of explaining the purpose of the methods just by looking at its name. In giving a name to methods the designer needs to
know what programming language will be used for the development so that the naming convention of that language will be used here.
Parameters: The names of parameters, and optionally their types and default values (if any);
Return value type: The data type of the return value (if available)
26
Cont…
Modeling AttributesAttributes are the data aspects of
objects. The design level will model more
information about attributes than the analysis.
The design level may include: Visibility: This is the level of access external objects have to an attribute.
27
Cont…28
Visibility Symbol Description
Public + A public attribute can be accessed by any other method in any other object or class.
Protected # A protected attribute can be accessed by any method in the class in which it is declared or by any method defined in subclasses of that class.
Private - A private attribute can only be accessed by method in the class in which it is declared, but not in the subclasses.
Cont…
Type: The data type of an attribute should be determined (could be a primitive type, such as string or int, or a class such as Address.)
Initial value: The initial value for an attribute should also be indicated (if available).
29
Cont…
Modeling Association Objects in any system cannot exist and work
alone. For this reason they need to depend one another or collaborate with each other. The dependency and collaboration will help the
development team to define how they interact with each other.
The collaboration is important as an object needs to know about another object to work with it.
For each association multiplicity should be modeled, one on each end of the association line
30
In Design Minimize coupling and Maximize cohesion
Coupling is a measure of how much two items, such as classes or methods, are interrelated. When one class depends on another class, we say they are coupled.
When one class interacts with another class, but does not know any of the implementation details of the other class, we say they are loosely coupled.
A class is coupled to another class when it has knowledge of that other class.
Low Coupling is important to reduce maintenance.In high coupling Class A and Class B, a change in B
could necessitate a change in A.
31
Cont…
Cohesion is a measure of how much an item, such as a class or method, makes sense.
A good measure of the cohesiveness of something is how long describing it takes using only one sentence: the longer it takes, the less cohesive it likely is. You want to design methods and classes that are highly cohesive.
32
Cont…
In other words, it should be completely clear what a method or class is all about.
A good rule of thumb is if you cannot describe a class or method with one sentence in less than 15 seconds, then it probably is not cohesive.
Classes should represent only one kind of object, and methods should do one thing and one thing well.
33
Following is an example to compare Analysis and design
versions of a class34
Analysis Level Design Level
18-35
Collaboration Diagrams
Collaboration Diagrams show the same information as a sequence diagram.
The emphasis is on the organization of the objects.
Sequence is shown by including a sequence number on the message.
18-36
Collaboration Diagram Example
Building Collaboration Diagram
1. place participating objects on the diagram2. draw the links between the objects using
the class diagrams as your guide3. add each event by placing the message
arrow parallel between the two objects4. position the arrow to point from the sender
to the receiver5. number the messages in order of execution6. repeat steps 3 and 4 until the entire
scenario has been modeled
37
18-38
Statechart Diagrams
Statechart diagrams show class states and the events that cause them to transition between states.
It is also called a state transition diagram
An event happens at a specific time and place.
They cause a change of state, or the transition “fires”
18-39
Statechart Diagrams (Continued)
Each time an object changes state, some of its attributes must change.
There must be a method to change the attributes.
Often there is a display screen or Web form to enter the attributes.
18-40
Statechart Diagrams (Continued)
Statechart diagrams are not created for all classes.
They are created when: A class has a complex life cycle. An instance of a class may update its
attributes in a number of ways through the life cycle.
A class has an operational life cycle. The object’s current behavior depends on
what happened previously.
18-41
Statechart Example
State chart …
A statechart diagram defines the behaviour of a single object
or of a set of objects related by a collaboration.
It captures the changes in an object throughout its lifecycle as
they occur in response to internal and external events.
The scope of a statechart is the entire life of one object.
42
State …
Statecharts are composed of: 1) states
a) initial state b) final state
2) events a) guard conditions b) actions c) event syntax
3) complex states a) activities b) entry actions c) exit actions
43
State
State is the current condition of an object reflected by the values of its attributes and its links to other objects.
The initial state identifies the state in which an object is created or constructed.
The initial state is called a pseudo-state because it does not really have the features of an actual state, but it helps clarify the purpose of another state of the diagram.
44
The final state is the state in which once reached, an object can never do a transition to another state.
The final state may also mean that the object has actually been destroyed and can no longer be accessed.
45
Event
DefinitionEvent is an occurrence of a stimulus that can
trigger a state transition.An event may be:1) the receipt of a signal, e.g. the reception of an
exception2) the receipt of a call, that is the invocation of an
operation,e.g. for changing the expiration date of a licenseAn event on a statechart diagram corresponds to a
message on a sequence diagram.
46
End of Part I47