Essential Software Architecture - Chapter 1 Understanding Software Architecture - Summary
This is brief summary of 'Essential Software Architecture by Ian Gorton.
Note: Only the first chapter.
Essential Software Architecture - Chapter 1 Understanding Software Architecture - Summary
This is brief summary of 'Essential Software Architecture by Ian Gorton.
Note: Only the first chapter.
Software architecture - what is it and why it's important.
Lecture for full-stack students in Elevation Academy.
What are the features and qualities we use to measure software architecture pattern performance. Some diagrams were taken from Oreilly's "Software architecture patterns" book.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
Design and Implementation in Software EngineeringKourosh Sajjadi
These slides were presented to the software engineering class held in IAUN. The main context is provided from the "Software Engineering" book authored by Sommerville.
Most of the icons used in the slides are provided in the flaticon.com website.
Thanks to our professor Habib Seifzadeh.
A cooperation with Mohammad Mostajeran.
In the GTU degree engineering, Software engineering is such a subject which is used to explore thinking over designing reliable softwares. In this presentation , Design concepts and principles are mentioned and explained in simplified manner.
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
Software architecture and software design are two aspects of the same topic. Both are about how software is structured in order to perform its tasks. The term "software architecture" typically refers to the bigger structures of a software system, whereas "software design" typically refers to the smaller structures.
Software engineering is a detailed study of engineering to the design, development and maintenance of software. Software engineering was introduced to address the issues of low-quality software projects.
Software architecture - what is it and why it's important.
Lecture for full-stack students in Elevation Academy.
What are the features and qualities we use to measure software architecture pattern performance. Some diagrams were taken from Oreilly's "Software architecture patterns" book.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
Design and Implementation in Software EngineeringKourosh Sajjadi
These slides were presented to the software engineering class held in IAUN. The main context is provided from the "Software Engineering" book authored by Sommerville.
Most of the icons used in the slides are provided in the flaticon.com website.
Thanks to our professor Habib Seifzadeh.
A cooperation with Mohammad Mostajeran.
In the GTU degree engineering, Software engineering is such a subject which is used to explore thinking over designing reliable softwares. In this presentation , Design concepts and principles are mentioned and explained in simplified manner.
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
Software architecture and software design are two aspects of the same topic. Both are about how software is structured in order to perform its tasks. The term "software architecture" typically refers to the bigger structures of a software system, whereas "software design" typically refers to the smaller structures.
Software engineering is a detailed study of engineering to the design, development and maintenance of software. Software engineering was introduced to address the issues of low-quality software projects.
Chapter 7 Design Architecture and Methodology1.docxmccormicknadine86
Chapter 7:
Design: Architecture and Methodology
1
Design Topics Covered
Architectural vs. detailed design
“Common” architectural styles, tactics, and reference architectures
Basic techniques for detailed design
Basic issues with user-interface design
2
Design
Starts mostly from/with requirements (evolving mostly from functionalities and other non-functional characteristics).
How is the software solution going to be structured?
What are the main components—(functional comp)?
Often directly from requirements’ functionalities
(use cases).
How are these components related?
Possibly re-organize the components (composition/decomposition).
Two main levels of design:
Architectural (high level)
Detailed design
How should we depict design—notation/language?
3
Relationship between Architecture and Design
Detailed Design
Comes from
Requirements &
Architecture
4
Software Architecture
Structure(s) of the solution, comprising:
Major software elements
Their externally visible properties
Relationships among elements
Every software system has an architecture.
May have multiple structures!
Multiple ways of organizing elements, depending on the perspective
External properties of components (and modules)
Component (module) interfaces
Component (module) interactions, rather than internals of components and modules
5
Views and Viewpoints
View – representation of a system structure
4+1 views (by Krutchen)
Logical (OO decomposition – key abstractions)
Process (run-time, concurrency/distribution of functions)
Subsystem decomposition
Physical architecture
+1: use cases
Other classification (Bass, Clements, Kazman)
Module
Run-time
Allocation (mapping to development environment)
Different views for different people
6
Architectural Styles/Patterns
Pipes and filters
Event driven
Client-server
Model-view-controller (MVC)
Layered
Database centric
Three tier
We discuss architectural styles/patterns as
“reusable” starting point for design activities.
7
Pipe-Filter Architecture Style
The high-level design solution is decomposed into two “generic” parts (filters and pipes):
Filter is a service that transforms a stream of input data into a stream of output data.
Pipe is a mechanism or conduit through which the data flows from one filter to another.
Input
time cards
Prepare for
check processing
Process checks
Problems that require batch file processing seem to fit this architecture: e.g., payroll, compilers, month-end accounting.
** Reminds one of DFD without the data store or source sink.**
8
Event Driven (Real Time)
The high-level design solution is based on an event dispatcher, which manages events and the functionalities that depend on those events. These have the following characteristics:
Events may be a simple notification or may include associated data.
Events may be prioritized or be based on constraints such as time.
Events may require synchronous or asynchronous processing.
Events may be “registered” ...
software design is very crusial thing to manage therfore software 'software design is very crusial thing to manage therfore software software design is very crusial thing to manage therfore software software design is very crusial thing to manage therfore software
This ppt covers the following topics:
Introduction
Data design
Software architectural styles
Architectural design process
Assessing alternative architectural designs
Thus it covers Architectural Design
Software Archtecture.
Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation.
Software design is the important step in SDLC (Software Design Life Cycle), which moves the concentration from problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.
Software design plays an important role in developing software: during software design, software engineers produce various models that form a kind of blueprint of the solution to be implemented
Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA).
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
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
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
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
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
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
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
Tunnel vision A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job, and the design concepts.
Traceability Because a single element of the design model often traces to multiple requirements
Don’t reinvent Time is short and resources are limited! previously used design patterns and integrating with new ones
Uniformity and integration A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.
Design ≠ Coding Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code.
Design quality A variety of design concepts and design measures are available to assist the designer in assessing quality.
Conceptual/Semantic errors There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model.
When these design principles are properly applied, the software engineer creates a design that exhibits both external and internal quality factors.
External quality factors are those properties of the software that can be readily observed by users (e.g., speed, reliability, correctness, usability).
Internal quality factors are of importance to software engineers. They lead to a high-quality design from the technical perspective. To achieve internal quality factors, the designer must understand basic design concepts and principles.