Scribd
Upload
179 views26 pages

Chapter 4a - High Level Design

The document discusses high level software design specifications including security, hardware, user interface, internal and external interfaces, architecture types, reports, outputs, databases, configuration data, data flows, and UML diagrams. It describes common elements to specify in high level design such as operating system security, application security, data security, network security, and physical security. It also outlines standard architecture types including monolithic, client/server, service-oriented, component-based, data-centric, event-driven, rule-based, distributed, and mixed approaches. Finally, it provides an overview of various UML diagrams for modeling a system including class, object, component, composite structure, package, deployment, activity, use case, state machine

Uploaded by

sagni
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
179 views26 pages

Chapter 4a - High Level Design

The document discusses high level software design specifications including security, hardware, user interface, internal and external interfaces, architecture types, reports, outputs, databases, configuration data, data flows, and UML diagrams. It describes common elements to specify in high level design such as operating system security, application security, data security, network security, and physical security. It also outlines standard architecture types including monolithic, client/server, service-oriented, component-based, data-centric, event-driven, rule-based, distributed, and mixed approaches. Finally, it provides an overview of various UML diagrams for modeling a system including class, object, component, composite structure, package, deployment, activity, use case, state machine

Uploaded by

sagni
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 26

High Level Design

Chapter 4a
Topics includes…
 Software Specifications
 UML
Software Specifications
Security. Your high‐level design should sketch out all
the application’s security needs. Those needs may
include the following:
 Operating system security
 Application security
 Data security
 Network security
 Physical security
Software Specifications cont…
Hardware. Additional hardware that you need to specify
might include the following:
 Printer
 Network components (cables, modems, gateways, and
routers)
 Servers (database servers, web servers, and application
servers)
 Specialized instruments (scales, microscopes, programmable
signs, and GPS units)
 Audio and video hardware (webcams, headsets, and VOIP)
Software Specifications cont…
User Interface. The high‐level user interface design can
describe special features such as clickable maps,
important tables, or methods for specifying system
settings (such as sliders, scrollbars, or text boxes). This
part of the design can also address general appearance
issues such as color schemes, company
logo placement, and form skins.
Software Specifications cont…
Internal Interfaces. When you chop the program into
pieces, you should specify how the pieces will interact.
Then the teams assigned to the pieces can work
separately without needing constant coordination.
External Interfaces. External interfaces are often easier
to specify than internal ones because you usually don’t
have control over both ends of the interface.
Software Specifications cont…
Architecture. An application’s architecture describes
how its pieces fit together at a high level. Developers
use a lot of “standard” types of architectures. Many of
these address particular characteristics of the problem
being solved.
Software Specifications cont…

Types of Architecture:
 Monolithic. In a monolithic architecture, a single program does
everything. It displays the user interface, accesses data, processes
customer orders, prints invoices, launches missiles, and does
whatever else the application needs to do.
 Client/Server. A client/server architecture separates pieces of the
system that need to use a particular function (clients) from parts of
the system that provide those functions (servers). That decouples
the client and server pieces of the system so that developers can
work on them separately.
 Service‐Oriented. A service‐oriented architecture (SOA) is similar
to a component‐based architecture except the pieces are
implemented as services. A service is a self‐contained program that
runs on its own and provides some kind of service for its clients.
Software Specifications cont…

Types of Architecture cont…


 Component‐Based. In component‐based software engineering
(CBSE), you regard the system as a collection of loosely coupled
components that provide services for each other.
 Data‐Centric. Data‐centric or database‐centric architectures
come in a variety of flavors that all use data in some central way.
 Event‐Driven. In an event‐driven architecture (EDA), various
parts of the system respond to events as they occur.
 Rule‐Based. A rule‐based architecture uses a collection of rules
to decide what to do next. These systems are sometimes called
expert systems or knowledge‐based systems.
Software Specifications cont…

Types of Architecture cont…


 Distributed. In a distributed architecture, different parts of the
application run on different processors and may run at the same
time. The processors could be on different computers scattered
across the network, or they could be different cores on a single
computer.
 Mix and Match. An application doesn’t need to stick with a
single architecture. Different pieces of the application might use
different design approaches.
Software Specifications cont…

Reports. Almost any nontrivial software project


can use some kinds of reports. Business
applications might include reports that deal with
customers (who’s buying, who has unpaid bills,
where customers live), products (inventory,
pricing, what’s selling well), and users (which
employees are selling a lot,
employee work schedules).
Software Specifications cont…

Other Outputs. In addition to normal reports, you


should consider other kinds of outputs that the
application might create. The application could
generate printouts (of reports and other things),
web pages, data files, image files, audio (to
speakers or to audio files), video, output to special
devices (such as electronic signs), e‐mail, or text
messages (which is as easy as sending an e‐mail to
the right address). It could even send messages to
pagers, if you can find any that aren’t in museums
yet.
Software Specifications cont…

Database. Database design is an important part of


most applications. The first part of database
design is to decide what kind of database the
program will need. You need to specify whether
the application
will store data in text files, XML files, a full‐
fledged relational database, or something more
exotic such as a temporal database or object store.
Categories includes the following:
 Audit Trails
 User Access
 Database Maintenance
Software Specifications cont…

Configuration Data. Users can fine‐tune the application


without making you write new code. Store parameters to
algorithms, key amounts, and important durations in the
database or in configuration files.
Data Flows and States. These kinds of diagrams help
describe the system and the way processes interact with
the data
Training. You can decide whether you want users to attend
courses taught by instructors, read printed manuals, watch
instructional videos, or browse documentation online.
UML

Structure Diagrams. A structure diagram


describes things that will be in the system you are
designing. For example, the class diagram (one
type of structure diagram) shows relationships
among the classes that will represent objects in
the system such as inventory items, vehicles,
expense reports, and coffee requisition forms.
UML cont…

Types of Structure Diagrams:


Class Diagram—Describes the classes that make up the system, their properties
and methods, and their relationships.
Object Diagram—Focuses on a particular set of objects and their relationships at
a specific time.
Component Diagram—Shows how components are combined to form larger
parts of the system.
Composite Structure Diagram—Shows a class’s internal structure and the
collaborations that the class allows.
Package Diagram—Describes relationships among the packages that make up a
system.
Deployment Diagram—Describes the deployment of artifacts (files, scripts,
executables, and the like) on nodes (hardware devices or execution
environments that can execute artifacts).
UML cont…

Behavior Diagrams. UML defines three kinds of basic behavior


diagrams: activity diagrams, use case diagrams, and
state machine diagrams.

Activity Diagrams. An activity diagram represents work flows


for activities. They include several kinds of symbols connected
with arrows to show the direction of the work flow.
UML cont…

Activity Diagram Example for Baking


Cookies.
UML cont…

Use Case Diagram. A use case diagram represents a user’s


interaction with the system. Use case diagrams show stick
figures representing actors (someone or something that
performs a task) connected to tasks represented by ellipses.
To provide more detail, you can use arrows to join subtasks
to tasks. Use the annotation <<include>> to mean the task
includes the subtask. (It can’t take place without the subtask.)
If a subtask might occur only under some circumstances,
connect it to the main task and add the annotation
<<extend>>. If you like, you can add a note indicating when
the extension occurs. (Usually both <<include>> and
<<extend>> arrows are dashed.)
UML cont…

A use case diagram shows actors and the tasks they


perform (possibly with subtasks and extensions).
UML cont…

State Machine Diagram. A state machine diagram shows the


states through which an object passes in response to various
events. States are represented by rounded rectangles. Arrows
indicate transitions from one state to another. Sometimes
annotations on the arrows indicate what causes a transition. A
black circle represents the starting state and a circled black
circle indicates the stopping state. Below is a state machine
diagram represents reading a floating point number.
UML cont…

Interaction Diagrams. Interaction diagrams are a


subset of activity diagrams. They include sequence
diagrams, communication diagrams, timing diagrams,
and interaction overview diagrams.

Categories:
Sequence Diagram. A sequence diagram shows how
objects collaborate in a particular scenario. It
represents the collaboration as a sequence of
messages.
UML cont…

A sequence diagram shows the timing of messages between


collaborating objects.
UML cont…

Categories cont…
Communication Diagram. Like a sequence diagram, a communication
diagram shows communication among objects during
some sort of collaboration. The difference is the sequence diagram focuses on
the sequence of messages, but the communication diagram focuses more on the
objects involved in the collaboration. Below is a communication diagram
emphasizes the objects participating in a collaboration.
UML cont…

Categories cont…
Timing Diagram. A timing diagram shows one or more objects’
changes in state over time. A timing diagram looks a lot like a sequence
diagram turned sideways, so time increases from left to right. These
diagrams
can be useful for giving a sense of how long different parts of a scenario
will take. More elaborate versions of the timing diagram show multiple
participants stacked above each other with arrows showing how
messages pass between the participants.
Interaction Overview Diagram. An interaction overview
diagram is basically an activity diagram where the nodes can be frames
that contain other kinds of diagrams. Those nodes can contain sequence,
communication, timing, and other interaction overview diagrams. This
lets you show more detail for nodes that represent complicated tasks.
End of Chapter 4a

You might also like