1

4 SYSTEM DESIGN
AND MODELING
Introduction 2
 System analysis modeling,
 concentrated on the identification, workflows and interactions among the
functional requirements of the evolving system.
 while, system design modeling incorporates the nonfunctional
requirements.
 That is, design modeling focuses on how the system will operate.
 The purpose of analysis is to figure out what the business needs
are, while the purpose of design is to decide how to build the
system.
 The major activity that takes place during design is evolving the set of
analysis representations into design representations.
… 3
 The initial part of design is examining several designing strategies,
and deciding which will be used to build the to-be system.
 System design modeling includes:
 Class and object design:
 To design individual classes and methods that are used to map out the nuts and
bolts of the system.
 Database design:
 To illustrate how the data generated by objects of the classes is going to be
stored.
 User interaction design:
 To depict how users are going to interact with the system.
 Deployment and architecture design:
 To model how the system is going to be deployed and organized for access.
Verify and validate the analysis models
4
 A system design model is evolved or derived from the system analysis
model after the analysis method has been verified and validated completely.
 System analysis model verification and validation involves:
 Balancing functional and structural models:
 Ensure that the use-case diagram, use-case descriptions and activity diagrams are
consistent with the class diagram and CRC-cards by cross checking
 If every class in the class diagram are associated with at least one use-case from the use-
case diagram.
 If every activity or action in an activity diagram related to one or more methods of the
class diagram (or responsibility in CRC-cards).
 If every object node on an activity diagram is associated with an instance of a class on a
class diagram (i.e., an object) and a CRC card or an attribute contained in a class and on a
CRC card.
 If every attribute and association/aggregation relationships contained on a CRC card (and
connected to a class on a class diagram) should be related to the subject or object of an
event in a use-case description.
… 5
 System analysis model verification and validation involves:
 Balancing functional and behavioral models:
 ensure the consistency of the activity diagrams, use-case descriptions, and
use-case diagrams with the sequence diagrams, communication diagrams and
behavioral state machines by cross-checking:-
 If all sequence and communication diagrams, are associated with a use case on the
use-case diagram and a use-case description.
 If all actors on sequence diagrams and communication diagrams, are associated
with actors on the use-case diagram or referenced in the use case description, and
vice versa.
 If all messages on sequence and communication diagrams, transitions on
behavioral state machines, are related to activities and actions on an activity
diagram and events listed in a use-case description, and vice versa.
 If all complex objects represented by an object node in an activity diagram must
have a behavioral state machine that represents the object’s lifecycle, and vice
versa.
… 6
 System analysis model verification and validation involves:
 Balancing structural and behavioral models:
 ensure the consistency of the CRC cards and class diagrams with the
sequence diagrams, communication diagrams and behavioral state
machines by cross-checking:-
 If all actors mentioned in sequence or communication diagram are
instance of the class in the class diagram..
 If all objects in a behavioral state machine diagram are instance of class in
the class diagram.
 If all objects in sequence and communication diagram instances of class in
the class diagram.
 If all the messages in sequence and communication diagrams are listed as
a method in one or more classes in the class diagram.
Evolving analysis models into design models
7
 Analysis model focuses on defining the functional
requirements,
 where as, design involves refining system analysis by
adding(considering) the non-functional requirements too.
 While evolving analysis model into design model, carefully review the use-
cases and the current set of classes (their attributes, operations and
relationships) by asking:
 Are all the classes necessary?
 Are there any missing classes?
 Are the classes fully defined?
 Are any attributes or methods missing?
 Do the classes have any unnecessary attributes and methods?
 Is the current representation of the evolving system optimal?
… 8
 There are three ways to evolve analysis models into design models:
1. Factoring:- is the process of separating out a module into a stand-alone
module.
 The new module can be a new class or a new method.
 The new class can be related to the existing classes using either
aggregation (has-parts) or generalization (a-kind-of) relationships.
 Example: Person class can be factored (or abstracted) from Library-Mgr,
Librarian and Student classes.
 Factoring involves abstraction and refinement; the above example is
abstraction.
 Refinement is quite the opposite, in refinement we identified additional
subclass(es) from the one class.
 Example: Book class can be refined into AcademicBook and
NonAcademicBook classes.
… 9
 There are three ways to evolve analysis models into design models:
2. Partitions and collaborations:- A partition is the object-oriented
equivalent of a subsystem, where a subsystem is a decomposition of a
larger system into its component systems.
 Partitioning is necessary, because the factoring, abstracting and refining of
classes is going to overwhelming the design.
 Partitioning is done by identifying the collaborating classes and group them
together into one component.
 Package diagrams suits best to illustrate subsystems( or components).
… 10
 There are three ways to evolve analysis models into design models:
3. Layers: layering involves illustrating the evolving system’s environment
(like the architecture design, data base design and user interface
design of the system).
• Foundation layer:-
• contains built-in classes for data types, date and time (or utility classes) and
classes for data structures. Ever modified by programmers.
• Problem domain layer:-
• involves a more detailed class diagram specifying coupling and cohesion.
• Data management layer:- is all about data base design using persistent
diagram.
• Human-computer interaction layer:- illustrates user interaction mechanisms.
• Physical architecture layer:- addresses how the software will execute on
specific computers and networks.
Package diagram 11
 In UML, collaborations, partitions, and layers can be represented
by a higher-level construct: a package.
 In fact, a package serves the same purpose as a folder on your computer.
 When packages are used in programming languages such as Java,
packages are actually implemented as folders.
 A package is a general construct that can be applied to any of the
elements in UML models.
 A package diagram is a diagram composed only of packages.
 A package diagram is effectively a class diagram that only shows
packages.
… 12
 A package diagram illustrates the organization and grouping of
related classes and components of a system into subsystems.
 It visually represents the dependencies and relationships between
these packages, helping to illustrate how different parts of a system
(subsystems) interact with each other.
Elements of a package diagram 13
 A package:
 Is a logical grouping of UML elements.
 Is used to simplify UML diagrams by grouping
related elements into a single higher-level
element.

 A dependency (or modification) relationship:

 Represents a dependency between packages: If a
package is changed, the dependent package also could
have to be modified.
 Has an arrow drawn from the dependent package
toward the package on which it is dependent.
… 14
Class diagram 15

• Class diagram can be used at the design level, in order to

illustrate the problem domain layer with a more specific details.
• Class diagram depicts the classes, their attributes, their operations and
the relationship among classes.
• While evolving the class diagram the following criterions should be
considered:-
• Coupling – refers how interdependent (or interrelated) the modules (like
classes, objects and methods) are in the system.
• Cohesion – refers to how single-minded a module (class, object, or method) is
within a system.
… 16
• Multiplicity:
Data management layer design
17

• A project team designs the data management layer of a system

using a four-step process:
• selecting the format of the storage,
• mapping the problem domain classes to the selected format,
• optimizing the storage to perform efficiently,
• and then designing the necessary data access and manipulation classes.
• While working on the data management layer design it’s
important to address:
• Fast access to the data in the database and
• Minimizing the cost of hardware for the storage devices.
… 18

• Therefore, the data management layer design includes both:

• the design of data manipulation & access classes
• and, the actual physical data storage.
• But, the design of data access and manipulation classes should
be independence from the data storage format.
• This allows the data (object) storage to be changed without
affecting the problem domain classes.
• The data storage component manages how data are stored and
handled by the program that runs the system.
Data storage component
19

• Practically there are five basic types of formats that can be used
to store objects for application systems:
• Files, Relational database, Object-relational database, Object-
oriented database and NoSQL data stores.
1. Files: - allows a sequential and random-access format list of
storing a data.
 Files are important for sequential access applications that only
requires read and write operations on the data.
 Files are very inefficient for update and search operations.
 Files also don’t support storing relational data at all.
… 20

2. Relational databases: - are the most popular kind of database for

application development.
 Relational database is a collections of tables with each table having a primary
key- a field(s) having a unique value for every row of the table.
 The tables in relational database can be related to one another by placing the
primary key from one table into the related table as a foreign key.
 RDMS supports a referential integrity, the idea of ensuring that values linking
the tables together through the primary and foreign keys are valid and
correctly synchronized.
 SQL, structured query language is the standard language for accessing and
manipulating the data in the table.
To use a RDBMS to store objects, objects must be converted so that they
can be stored in a table. From a design perspective, this entails mapping a
UML class diagram to a relational database schema
… 21

3. Object-relational databases: - are typically object-oriented

extensions to RDBMSs, they inherit the strengths of RDBMSs.
 Object-relational database management systems (ORDBMSs) are
relational database management systems with extensions to handle
the storage of objects in the relational table structure.
 This is typically done through the use of user-defined types.
 For example, an attribute in a table could have a data type of map,
which would support storing a map. This is an example of a complex
data type.
 In pure RDBMSs, attributes are limited to simple or atomic data types,
such as integers, floats, or chars.
… 22
 ORDBMSs, because they are simply extensions to their RDBMS,
have very good support for the typical data management
operations including:
 an easy-to-use query language (SQL),
 authorization,
 concurrency-control,
 and recovery facilities.
 Many of the ORDBMSs still do not support all of the object-
oriented features in an object-oriented design (e.g., like
inheritance).
 Like RDBMSs, a mapping from a UML class diagram to an
object-relational database schema is required.
Mapping problem domain objects to RDBMS
23
• Rules applied to map objects (class-diagram) into RDBMS tables:-
1. Map all concrete-problem domain classes to the RDBMS tables. Also, if an abstract Problem
Domain class has multiple direct subclasses, map the abstract class to a RDBMS table.
2. Map single-valued attributes to columns of the tables.
3. Map methods to stored procedures or to program modules.
4. Map single-valued aggregation and association relationships to a column that can store the
key of the related table, i.e., add a foreign key to the table. Do this for both sides of the
relationship.
5. Map multivalued attributes and repeating groups to new tables and create a one-to-many
association from the original table to the new ones.
6. Map multivalued aggregation and association relationships to a new associative table that
relates the two original tables together. Copy the primary key from both original tables to the
new associative table, i.e., add foreign keys to the table.
7. For aggregation and association relationships of mixed type, copy the primary key from the
single-valued side (1..1 or 0..1) of the relationship to a new column in the table on the
multivalued side (1..* or 0..*) of the relationship that can store the key of the related table,
i.e., add a foreign key to the table on the multivalued side of the relationship.
… 24
• Rules applied to map objects (class-diagram) into RDBMS tables:-
8. Rule 8a: Ensure that the primary key of the subclass instance is the same as the
primary key of the superclass. The multiplicity of this new association from the
subclass to the “superclass” should be 1..1. If the super classes are concrete, that
is, they can be instantiated themselves, then the multiplicity from the superclass
to the subclass is 0..1, otherwise, it is 1..1. Furthermore, an exclusive-or (XOR)
constraint must be added between the associations. Do this for each superclass.
Or
9. Rule 8b: Flatten the inheritance hierarchy by copying the superclass attributes
down to all of the subclasses and remove the superclass from the design.*
… 25
• Example:- Map the CD - for Set Appointment
in relational database design
… 26
Mapping problem domain objects to ORDBMS
27
• Rules applied to map objects (class-diagram) into ORDBMS tables:-
1. Map all concrete Problem Domain classes to the ORDBMS tables. Also, if an
abstract problem domain class has multiple direct subclasses, map the abstract
class to an ORDBMS table.
2. Map single-valued attributes to columns of the ORDBMS tables.
3. Map methods and derived attributes to stored procedures or to program modules.
4. Map single-valued aggregation and association relationships to a column that can
store an Object ID. Do this for both sides of the relationship.
5. Map multivalued attributes to a column that can contain a set of values.
6. Map repeating groups of attributes to a new table and create a one-to-many
association from the original table to the new one.
7. Map multivalued aggregation and association relationships to a column that can
store a set of Object IDs. Do this for both sides of the relationship.
… 28

• Rules applied to map objects (class-diagram) into ORDBMS

tables:-
8. Rule 8: For aggregation and association relationships of mixed type (one-
to-many or many-to-one),

on the single-valued side (1..1 or 0..1) of the relationship, add a column that
can store a set of Object IDs. The values contained in this new column will be
the Object IDs from the instances of the class on the multivalued side.

On the multivalued side (1..* or 0..*), add a column that can store a single
Object ID that will contain the value of the instance of the class on the single-
valued side.
… 29
• Rules applied to map objects (class-diagram) into ORDBMS tables:-
For generalization/inheritance relationships:
9. Rule 9a: Add a column(s) to the table(s) that represents the subclass(es) that will
contain an Object ID of the instance stored in the table that represents the
superclass. This is similar in concept to a foreign key in an RDBMS. The
multiplicity of this new association from the subclass to the “superclass” should
be 1..1. Add a column(s) to the table(s) that represents the superclass(es) that
will contain an Object ID of the instance stored in the table that represents the
subclass(es). If the super classes are concrete, that is, they can be instantiated
themselves, then the multiplicity from the superclass to the subclass is 0..1,
otherwise, it is 1..1. An exclusive-or (XOR) constraint must be added between the
associations. Do this for each superclass. or
10. Rule 9b: Flatten the inheritance hierarchy by copying the superclass attributes
down to all of the subclasses and remove the superclass from the design.*
… 30
HCI layer design
31

• A user interface is the part of the system with which the users
interact. From the user’s point of view, the user interface is the
system.
• It includes:
• the screen displays that provide navigation through the system,
• the screens and forms that capture data,
• and the reports that the system produces (whether on paper, on
the screen, or via some other medium).
• Interface design is the process of defining how a system will
interact with external entities (e.g., customers, suppliers, other
systems).
… 32
• The HCI layer defines how users interact with the system and the nature of
the inputs and outputs that the system accepts and produces.
• The UI of the HCI layer is independent of the data management layer.
• But it is dependent on both the problem domain and physical architecture
layers.
• Even though there are command-line user interfaces (e.g., Terminal on Mac
OSX), we are only focusing on GUI that use windows, menus, icons, etc.
• GUI-based user interface comprises three fundamental parts:-
• Navigation mechanism- buttons, menus, links and etc.
• Input mechanism:- forms
• Output mechanism:- tables, reports, webpages and etc.
Principles of good GUI design 33
• Layout –
• The interface should be a series of areas on the screen that are used consistently
for different purposes. For example, a top area for commands and navigation, a
middle area for information to be input or output, and a bottom area for status
information.
• Content Awareness –
• Users should always be aware of where they are in the system and what
information is being displayed.
• Aesthetics –
• Interfaces should be functional and inviting to users through careful use of white
space, colors, and fonts. Tradeoff between whitespace or content.
… 34
• User Experience –
• Although ease of use and ease of learning often lead to similar design decisions,
sometimes there is a trade-off between use or learning
• Consistency –
• Consistency in interface design enables users to predict what will happen before
they perform a function. It is one of the most important elements in ease of
learning, ease of use, and aesthetics.
• Minimal User Effort –
• The interface should be simple to use. Most designers plan on having no more
than three mouse clicks from the starting menu until users perform work.
… 35
• To achieve the above principles of good GUI design, understanding how
human brain perceive information (Gestalt Psychology) is important:
• Figure ground:- brain perceives based on the differentiation of foreground and
background.
• Proximity: - when elements are placed close together, they tend to be perceived as
a whole.
• Closurity:- our brain fills a gap, when an object is incomplete or a space is not
completely enclosed.
• Continuity:- Continuation occurs when the eye is compelled to move through one
object and continue to another object
• Similarity:- Similarity occurs when objects look similar to one another. People
often perceive them as a group or pattern.
… 36

• GUI-design can be started as a low-fidelity prototype and then

evolves into medium and high-fidelity prototypes.
• Low-fidelity prototypes are pencil sketches of the UI.
• Medium-fidelity prototypes are a more detailed and colorful design
of the UI, using tools like MS Word, Sketch, WYIWYG, InVision and
etc.
• High-fidelity prototypes includes every tiny detail that should be
included in the UI including, font types, font sizes, terminologies,
colors, images and etc.
… 37
… 38
Physical layer design
39

• A physical architecture describes the system’s hardware,

software, and network environment.
• The physical architecture layer design flows primarily from the
nonfunctional requirements, such as operational, performance, security,
cultural, and political requirements.
• Most information systems are spread across multiple computers.
• A Web-based system, for example, runs in the browser on a desktop
computer but interacts with the Web server (and possibly other
computers) over the Internet.
• A system that operates completely inside a company’s network may have
a Visual Basic program installed on one computer but interact with a
database server elsewhere on the network.
… 40

• Therefore, an important step of design is the creation of the

physical architecture layer design,
• the plan for how the system will be distributed across the
computers,
• and what hardware and software will be used for each computer.
• Although there are numerous ways the software components can be
placed on the hardware components, there are three principal
application architectures in use today:
• server-based architectures,
• client-based architectures,
• and client–server architectures.
… 41

• Server-based architecture:
• the server performing all four functions.
• the clients enabled users to send and receive messages to and from the server.
• Application software is developed and stored on one computer, and all data are on
the same computer.
• Server will get busy.
… 42

• Client-based architecture:
• the clients are personal computers on a local area network (LAN), and the server
computer is a server on the same network.
• The application soft ware on the client computers is responsible for the
presentation logic, the application logic, and the data access logic; the server
simply stores the data
• Problem is data has to be traveled to client side for processing.
… 43

• Client-server architecture:
• Tries to balance the workload on client and server. The client is responsible for
the presentation logic, whereas the server is responsible for the data access
logic and data storage.
• Client-server architectures are scalable.
• Client-server architectures can be 2-tier, 3-tier, 4-tier or n-tier architectures
based on how the application layer is split between client and server.
… 44

• Deployment diagram:
• Deployment diagrams are used to represent the relationships between the
hardware components used in the physical infrastructure of an information
system.
• For example, when designing a web-based information system that will use a
wide area network, a deployment diagram can be used to show the
communication relationships client, database server and application server.
… 45