1. How to Construct?

2.  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

3. • Designing of object oriented software requires
– the definition of a multilayered software architecture,
– the specification of subsystems that perform required
functions and provide infrastructure support,
– a description of objects (classes) that form the building
blocks of the system, and
– a description of the communication mechanisms that allow
data to flow between layers, subsystems, and objects.
• Object-oriented design accomplishes all of these
things.
3

4.  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; Conceptual model, Use case,
Sequences Diagram and User interface.
4

5. Analysis Design Construction
Investigation
of problem
Logical solution Code

6.  Design is defined as
◦ a meaningful engineering representation of something
that is to be built.
◦ both “the process of defining 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

7.  More precisely, a software design (the result)
must describe
◦ The software architecture (high level) 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.(low level)
 In the software engineering context, design
focuses on four major areas of concern:
◦ data, architecture, interfaces, and components.
7

8.  Would you try to build a house without a
blueprint? You’d risk confusion, errors, a floor plan
that didn’t make sense, windows and doors in the
wrong place . . . a mess.
 Computer software is considerably more complex
than a house; hence, we need a blueprint  the
design.
 It can be traced to a customer’s requirements
and at the same time assessed for quality
against a set of predefined criteria for “good”
design.
8

9.  At each stage, software design work
products are reviewed for
 Clarity,
 Correctness,
 Completeness, and
 Consistency
◦ with the requirements and with one
another.
9

10.  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
10

11.  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.
11

12.  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.
12

13.  What to design? Some examples are…
◦ – Process and association
◦ --User Interfaces
◦ – Storage
◦ – Networking/Distribution
 • Each may requires the addition of extra
classes and associations.
13

14. 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

15.  Heuristics in grouping objects in to subsystems
◦ The initial subsystem decomposition should derived
from the functional requirements.
◦ Assign objects identified in one use case in to same
subsystem
◦ All objects in the same subsystem should be
functionally related
◦ Minimize the number of association crossing
subsystem boundaries
15

16.  Some of the major architectural styles includes;
◦ Client-Server (two or three-tier)
 Keeping in mind the hardware as service consumer and providers
 Some how similar with repository but not restricted with one server. (ex
WWW)
◦ MVC (model, view, controller)
 Model – main functionality of the application
 Controller – accepts user inputs in a form of events that trigger the
execution of operation with in the model (mange sequence of interaction
with users)
 View – corresponds to a particular style and format of presentation of
information to the user.
 Has some similarity with entity, boundary(UI) and control objects.
16

17. Repository based
Is typical architecture for DBMS
Subsystems access and modify data from single data
structure called central repository
Peer-to-peer architecture
Is a generalization of client/server architecture in which
subsystem can act both as a client and/or as a server
17

18. 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
18

19. 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
19

20. ◦ 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
20

21.  Major concerns are
◦ Understanding objects to the level required for
implementation
◦ Providing as much specification details as possible
21

22.  Class Type Architecture - Architectural aspect
◦ (not in UML)
 Design level Class diagrams – Detail design aspect
◦ Also called object design
 State chart diagrams - Detail design aspect
 Collaboration diagrams - Detail design aspect
 Component models - Architectural aspect
 Deployment diagrams - Architectural aspect
 Persistent diagram – Both aspects
 Evolving UI – Both aspects
 Other design issues – (design goals, access and security
…)
22

23.  A common architectural strategy, some might call
it a pattern, is to layer the architecture of a system
into several layers/strata.
 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
I've found (the author) that it isn't quite so simple.
23

24.  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
24

25. 25

26.  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 Seminar, focusing
on the data aspects of the business objects, plus
behaviors specific to individual objects
26

27.  Process
◦ The process layer implements business logic that involves
collaborating with several domain classes or even other process
classes
 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
27

28.  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.
28

29.  There will be changes to be introduced to the
analysis class model based on
implementation technologies.
 This gives the developers the chance to
make amendments and modification to
improve the quality of the system.
 Changes will also be forced into the class
model due to the implementation technology
to be used.
29

30.  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.
30

31.  The design level may include:
◦ Visibility: the level of access that external
objects have to a method.
◦ 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.
31

32. 32
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.

33.  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)
33

34.  Example
+IsEligible (name:string …..):
Boolean
(Visisbilty, name, Parameter, return type)
34

35.  Modeling Attributes
◦ Attributes 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.
35

36. 36
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.

37.  Name: descriptive name to
attributes.
◦ A good attribute name is the one that is
capable of explaining the purpose of the
attribute just by looking at its name.
◦ Attributes that are collections, such as arrays,
should be given names that are plural to
indicate they represent multiple values, the
rest should be singular.
37

38. ◦ In giving a name to attributes 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.
◦ The most important technique for designing
and using attributes effectively is not to
access them directly in your code.
38

39. ◦ Following are some of the recommendations:
 Assign private visibility to all attributes;
 Update attributes only in their setter methods;
 Directly access attributes only in their getter
methods;
 enforce simple validation logic for an attribute in its
setter method;
 Implement complex validation logic in separate
methods; and
 Apply initialization in getter methods for attributes
39

40.  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).
40

41.  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
 Role , name and clear symbol for aggregation and generalization
should also be reviewed.
41

42.  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.
 Coupling is important because when Class A is
coupled to Class B, a change in B could necessitate a
change in A.
42

43.  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.
43

44.  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.
44

45. 45
Analysis Level Design Level

46.  Collaboration Diagrams show the same
information as a sequence diagram.
◦ Semantically similar
 The emphasis is on the organization of the
objects.
 Sequence is shown by including a
sequence number on the message.
18-
46

47. 18-
47

48.  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-
48

49.  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-
49

50.  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-
50

51. 18-
51

52. Translate/Convert the above state chart Diagram in to
Activity Diagram?
52

53. 53