Architecture development process
Requirements -> Design -> Development -> Test-> Maintenance
Design :
- Clarify intentions.
- Make explicit the decisions.
- Allow system-level analysis.
Maintenance :
Reduce maintenance costs directly and indirectly.
Software Architecture
· The architecture of a program or computing system is the structure or structures of the system, and comprising the components of the software, their properties externally visible, and the relationships between them.
· The software architecture design is a level different from the algorithms and data structures.
"The design and specification of the structure of the system as a whole is then another problem."
·
The elements structural include:
or control the organization and global
or communication protocols,
or physical distribution,
or the composition of design elements,
or the scalability and performance, and
or the choice between design alternatives.
Summary:
• A high-level design.
• The structure of the system.
• The components of a program or system, their relationships, and principles that govern their design and its evolution over time.
• Components and connectors.
• Components, connectors, configuration and restrictions.
No single definition ...
Why Software Architecture?
·
People need to think, design, coding, and communicate in terms of
major conceptual blocks.
Abstraction
· It is necessary to escape the overly customized developments and standardize the design .
Reusing architectural patterns
· It is necessary to design long life systems.
Reuse of particular components
· Productivity in development: currently only reuse code and data structures.
· Attacking other problems of software life cycle: modifiability, portability, scalability, security.
· As the system size grows, solutions to these problems lie more in the architecture.
· Having a common language for designers, developers and users.
Lifecycle Architecture
• The objectives of the organization influence the requirements.
• The requirements lead to architectural design.
• The architecture results in a system.
• Systems built suggest new opportunities for the organization and new requirements.
Development Stages Based on Architecture
1. Making a business case for the system
Two. Understand the requirements
Three. Create or select an architecture
April. Represent and communicate the architecture
May. Analyze or evaluate the architecture
June. Implementing the system based on the architecture
July. Ensure that the implementation conforms to the architecture
How do you make a good architecture?
• The architecture should be produced by a single architect or a small group .
• The architect must have the technical requirements of the system and a
prioritized list of qualitative properties that the software is expected to satisfy .
• The architecture should be well documented using a notation agreed that all
stakeholders can understand with little effort.
• To provide the architecture to stakeholders, which should be actively involved in their review.
How do you make a good architecture?
· The architecture should be analyzed to check their quantitative and qualitative properties before it's too late to change it.
· The architecture should allow creating a skeleton system which will reflect all roads but with minimal functionality.
· The architectural design should result in a specific set of critical areas of resource consumption, whose decision shall be clearly documented and maintained.
What is a good architecture?
• The modules must be designed with the principle of separation of concerns
- Different working groups can develop independently
• The hidden information include everything dependent infrastructure.
• Each module will have a defined interface that hides the other modules changeable aspects.
• The architecture should not depend on a particular version of a commercial product. If so, it must be structured so that it is easy and cheap to change.
What is a good architecture?
• The modules produced and consumed data should be separated:
- This tends to increase the maintainability because usually only a portion changes.
• Each task or process should be described so that their assignment to a
processor specific can be easily changed, even during execution.
• The architecture must follow one or a few patterns of interaction:
- Greater understanding, reduced development time, increased reliability, greater modifiability.
Importance of Architecture
• communication between the people involved,
• Early documentation of design decisions,
• implementation restrictions,
• the architecture dictates the organizational structure,
• facilitates or inhibits system properties
• to predict system qualities,
• facilitates the administration of evolution,
• transferable abstraction of the system,
• share product lines architecture
• basis for new user training.
We have 2 vocabularies with complementary foci:
Structure components and connectors
Properties : policies and mechanisms
? "Evaluable"? ? "Handy"?
Solution evaluable:
Should allow assessment commitments and options
• Therefore, you must have traceability between parts of the solution and the problem
• manageable Process: Must be partitioned and indicate dependencies
• Partitions : natural units of work assignment
• Dependencies : the basis for defining calendar
• Solution must satisfy requirements
The architect must:
• Describe a system
• Describe a process to build
• An architecture must be more than a list of products and more than just a component model
Quality architecture
• As recognized good architecture?
Necessary and sufficient
Good architecture = good description of good solution
• 3 key dimensions
Effective : provides the functions and properties specified
Minimum : has the least possible parts ("fewer moving parts")
"Grow one "anticipates potential movers and allows future work
Traceability Techniques
• fundamental notion architecture
Traceability: to justify a decision in the context of the document
• Models must provide information
Refinement: explained or apparent (Storytelling (Ask Kevin)?)
Layers : each mappable
• A good architecture "tells a story" to explain not only what and how, but why allow informed decisions to future
Summarizing
• The role of the architect ...
It makes sense for projects and organizations
There is a process context and partners
It is essential to produce systems that evolve and be scalable
• Applies to technology to help an organization in a domain
Rendering architectures
• Domain Models vs. software models
• Refinement
-Progressive Refinement, "tell a story"
-Levels of abstraction, layered models
• Views
-Views and Perspectives
-Views synchronic and diachronic
-Booch, OMT, 4 +1, RM
-ODP, Zachman
• UML, RM languages
-ODP, other notations
• Architecture Description Languages
Views
• Sources of complexity
-Unclear
-Intangibility
Running-Concurrency
-Construction Concurrency
-Diversification
• (Product Lines)
-Size
• Representation of a (sub-) system ...
- Partial ...
- ... From the perspective
• Idea:
-Participants need to reason about the system
-Provide information to suppress irrelevant details
• Vista = representation of a set of elements of the system and relationships associated with them (Clements)
• Perspective = concerns of a participant
• Outline view = view definitions and perspectives associated
Architectural structures and views
The architectural structures can be Divided into three main groups, depending on the nature from its elements:
• Modules Structures
-They are units of implementation.
-They are assigned functional responsibilities.
-No matter how manifest at runtime.
-That functionality is assigned to that module?
-What other software can be used by a module?
-What software elements are actually used by a module?
-They relate modules from a generalization?
• Structure of Components and Connectors
-Here the elements are components (mainframe computing) and Connectors (means of communication between the components).
-The components and connectors are manifested at runtime.
-What are the main executable components and how they interact?
-What are the main repositories of data?
-What parts of the system are replicated?
-As data flows in the system?
That part of the system, running in parallel?
Assigning Structures
-Allocation structures show the relationship between the software elements and the elements of the environment or environment in which the software is created and executed.
-In that processor or server software running that element?
-As software organizes the elements in the filesystem? In that project code files or software elements reside during development or testing?
-As elements are assigned software development teams?
Uses of Architecture
• Education
-Abstract, easily understood;
-Acquaint people with the system;
-New members, new architect, outsiders.
• Communication
-Guide for building;
-Basis for negotiation among the various stakeholders;
-Repository interrelated decisions.
• Analysis
Full-information to analyze different characteristics;
-Different tests require different information:
• performance, security, usability, availability, modifiability.
Size of Modules
• "A module is small enough when compared to a change, would be so burdensome as recode modify. "
[Parnas86]
• Who is not able to estimate the size and complexity of the code in a component is probably not appropriate software architect.
Interfaces
• edge or boundary (boundary) through which two independent entities interact or communicate.
• An interface is just a set of services offered. What more?
• The interface documentation should contain sufficient information to avoid unexpected interactions result of assumptions about the environment or other entities.
Views (views) or Structures
• The software architecture is a complex artifact can not be expressed in a form
simple and one-dimensional.
• "Documenting an architecture is documenting the relevant views and then add the information that applies to more than one view."
• A view is a representation of a set of system elements and the relationships associated with them.
• The views used depend on the needs and will use that architecture.
-Views and Styles
Types of views (viewtypes)
• Modules
-Structure in terms of implementation units;
• Components and Connectors (C & C)
-Structure in terms of interacting elements during implementation;
• Allocation (distribution, placement, assignment)
-Relationship between the system and external structures of the environment.
• The type of view limits the elements and relationships that contains a view that.
Styles (styles)
• An architectural style is a specialization of a type of view that sets
Elements and relationships,
-A number of restrictions on how they can be used.
• A style defines a family of architectures that satisfy these restrictions.
• The choice of a style determines the elements and the constraints which they document:
Style-guide.
• Style layers
module type.
-The system will have certain characteristics modifiability, portability, regardless of the content of the modules.
• Customer Style
Server-type C & C.
-There are clients, servers and protocols,
-Features like easy to create new customers.
• The styles are specializations of the types of views, and the views are instances of a style for a particular system.
Mixture of Styles
• Different parts of the system may have different styles:
-There are elements bridge between different views of each style,
-Usually through different interfaces that allow you to interact with one or another style.
• An element within a style is made following other style elements.
• One system can be seen from different points of view and different styles.
Modules and Components
• Modules
-Design units;
-Enclose or liability functionality is accessed through an interface [Parnas72];
-Not replicated;
-Not interested in running.
• Components
-Execution unit;
-Has a defined interface and accessible during execution;
-Can be installed independently;
-Can replicate.
0 comments:
Post a Comment